All of lore.kernel.org
 help / color / mirror / Atom feed
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(-)
> 

WARNING: multiple messages have this Message-ID (diff)
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(-)
> 

  parent reply	other threads:[~2015-03-02 13:26 UTC|newest]

Thread overview: 41+ 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 ` 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   ` Martin Hicks
2015-02-20 17:00 ` [PATCH 2/2] crypto: talitos: Add AES-XTS Support Martin Hicks
2015-02-20 17:00   ` Martin Hicks
2015-02-27 15:46   ` Horia Geantă
2015-02-27 15:46     ` Horia Geantă
2015-03-06  0:16   ` Kim Phillips
2015-03-06  0:16     ` Kim Phillips
2015-03-06 16:49     ` Martin Hicks
2015-03-06 16:49       ` Martin Hicks
2015-03-06 19:28       ` Martin Hicks
2015-03-06 19:28         ` Martin Hicks
2015-03-07  1:16       ` Kim Phillips
2015-03-07  1:16         ` Kim Phillips
2015-03-09  9:22         ` Horia Geantă
2015-03-09  9:22           ` Horia Geantă
2015-03-02 13:25 ` Horia Geantă [this message]
2015-03-02 13:25   ` [PATCH 0/2] crypto: talitos: Add AES-XTS mode Horia Geantă
2015-03-02 14:37   ` Milan Broz
2015-03-02 22:09     ` Martin Hicks
2015-03-02 22:09       ` Martin Hicks
2015-03-03 15:44       ` Horia Geantă
2015-03-03 15:44         ` Horia Geantă
2015-03-03 17:44         ` Martin Hicks
2015-03-03 17:44           ` Martin Hicks
2015-03-09 10:16           ` Horia Geantă
2015-03-09 10:16             ` Horia Geantă
2015-03-09 15:08             ` Martin Hicks
2015-03-09 15:08               ` Martin Hicks
2015-03-11 15:48               ` Horia Geantă
2015-03-11 15:48                 ` Horia Geantă
2015-03-13 14:08                 ` Martin Hicks
2015-03-13 14:08                   ` Martin Hicks
2015-03-16 18:46                   ` Horia Geantă
2015-03-16 18:46                     ` Horia Geantă
2015-03-02 21:44   ` Martin Hicks
2015-03-02 21:44     ` Martin Hicks
2015-03-02 22:03     ` 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.