From: "Horia Geantă" <horia.geanta@freescale.com>
To: Martin Hicks <mort@bork.org>,
Kim Phillips <kim.phillips@freescale.com>,
Scott Wood <scottwood@freescale.com>,
Kumar Gala <galak@kernel.crashing.org>,
Milan Broz <gmazyland@gmail.com>,
Herbert Xu <herbert@gondor.apana.org.au>
Cc: linuxppc-dev@lists.ozlabs.org, linux-crypto@vger.kernel.org
Subject: Re: [PATCH 0/2] crypto: talitos: Add AES-XTS mode
Date: Mon, 2 Mar 2015 15:25:56 +0200 [thread overview]
Message-ID: <54F464E4.8080204@freescale.com> (raw)
In-Reply-To: <1424451610-5786-1-git-send-email-mort@bork.org>
On 2/20/2015 7:00 PM, Martin Hicks wrote:
> This adds the AES-XTS mode, supported by the Freescale SEC 3.3.2.
>
> One of the nice things about this hardware is that it knows how to deal
> with encrypt/decrypt requests that are larger than sector size, but that
> also requires that that the sector size be passed into the crypto engine
> as an XTS cipher context parameter.
>
> When a request is larger than the sector size the sector number is
> incremented by the talitos engine and the tweak key is re-calculated
> for the new sector.
>
> I've tested this with 256bit and 512bit keys (tweak and data keys of 128bit
> and 256bit) to ensure interoperability with the software AES-XTS
> implementation. All testing was done using dm-crypt/LUKS with
> aes-xts-plain64.
>
> Is there a better solution that just hard coding the sector size to
> (1<<SECTOR_SHIFT)? Maybe dm-crypt should be modified to pass the
> sector size along with the plain/plain64 IV to an XTS algorithm?
AFAICT, SW implementation of xts mode in kernel (crypto/xts.c) is not
aware of a sector size ("data unit size" in IEEE P1619 terminology):
There's a hidden assumption that all the data send to xts in one request
belongs to a single sector. Even more, it's supposed that the first
16-byte block in the request is "block 0" in the sector. These can be
seen from the way the tweak ("T") value is computed.
(Side note: there's no support of ciphertext stealing in crypto/xts.c -
i.e. sector sizes must be a multiple of underlying block cipher size -
that is 16B.)
If dm-crypt would be modified to pass sector size somehow, all in-kernel
xts implementations would have to be made aware of the change.
I have nothing against this, but let's see what crypto maintainers have
to say...
BTW, there were some discussions back in 2013 wrt. being able to
configure / increase sector size, smth. crypto engines would benefit from:
http://www.saout.de/pipermail/dm-crypt/2013-January/003125.html
(experimental patch)
http://www.saout.de/pipermail/dm-crypt/2013-March/003202.html
The experimental patch sends sector size as the req->nbytes - hidden
assumption: data size sent in an xts crypto request equals a sector.
I am not sure if there was a follow-up though...
Adding Milan - maybe he could shed some light.
Thanks,
Horia
>
> Martin Hicks (2):
> crypto: talitos: Clean ups and comment fixes for ablkcipher commands
> crypto: talitos: Add AES-XTS Support
>
> drivers/crypto/talitos.c | 45 +++++++++++++++++++++++++++++++++++++--------
> drivers/crypto/talitos.h | 1 +
> 2 files changed, 38 insertions(+), 8 deletions(-)
>
next prev parent reply other threads:[~2015-03-02 13:41 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-20 17:00 [PATCH 0/2] crypto: talitos: Add AES-XTS mode Martin Hicks
2015-02-20 17:00 ` [PATCH 1/2] crypto: talitos: Clean ups and comment fixes for ablkcipher commands Martin Hicks
2015-02-20 17:00 ` [PATCH 2/2] crypto: talitos: Add AES-XTS Support Martin Hicks
2015-02-27 15:46 ` Horia Geantă
2015-03-06 0:16 ` Kim Phillips
2015-03-06 16:49 ` Martin Hicks
2015-03-06 19:28 ` Martin Hicks
2015-03-07 1:16 ` Kim Phillips
2015-03-09 9:22 ` Horia Geantă
2015-03-02 13:25 ` Horia Geantă [this message]
2015-03-02 14:37 ` [PATCH 0/2] crypto: talitos: Add AES-XTS mode Milan Broz
2015-03-02 22:09 ` Martin Hicks
2015-03-03 15:44 ` Horia Geantă
2015-03-03 17:44 ` Martin Hicks
2015-03-09 10:16 ` Horia Geantă
2015-03-09 15:08 ` Martin Hicks
2015-03-11 15:48 ` Horia Geantă
2015-03-13 14:08 ` Martin Hicks
2015-03-16 18:46 ` Horia Geantă
2015-03-02 21:44 ` Martin Hicks
2015-03-02 22:03 ` Martin Hicks
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=54F464E4.8080204@freescale.com \
--to=horia.geanta@freescale.com \
--cc=galak@kernel.crashing.org \
--cc=gmazyland@gmail.com \
--cc=herbert@gondor.apana.org.au \
--cc=kim.phillips@freescale.com \
--cc=linux-crypto@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=mort@bork.org \
--cc=scottwood@freescale.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).