linuxppc-dev.lists.ozlabs.org archive mirror
 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(-)
> 

  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).