Re: [PATCH 0/2] crypto: talitos: Add AES-XTS mode

2015-03-16 Thread Horia Geantă 
On 3/13/2015 4:08 PM, Martin Hicks wrote:
 Hi Horia,
 
 On Wed, Mar 11, 2015 at 11:48 AM, Horia Geantă
 horia.gea...@freescale.com wrote:

 While here: note that xts-talitos supports only two key lengths - 256
 and 512 bits. There are tcrypt speed tests that check also for 384-bit
 keys (which is out-of-spec, but still...), leading to a Key Size Error
 - see below (KSE bit in AESU Interrupt Status Register is set)
 
 Ok.  I've limited the keysize to 32 or 64 bytes for AES-XTS in the
 talitos driver.
 
 This was my first experiments with the tcrypt module.  It also brought
 up another issue related to the IV limitations of this hardware.  The
 latest patch that I have returns an error when there is a non-zero
 value in the second 8 bytes of the IV:
 
 +   /*
 +* AES-XTS uses the first two AES Context registers for:
 +*
 +* Register 1:   Sector Number (Little Endian)
 +* Register 2:   Sector Size   (Big Endian)
 +*
 +* Whereas AES-CBC uses registers 1/2 as a 16-byte IV.
 +*/
 +   if ((ctx-desc_hdr_template 
 +(DESC_HDR_SEL0_MASK | DESC_HDR_MODE0_MASK)) ==
 +(DESC_HDR_SEL0_AESU | DESC_HDR_MODE0_AESU_XTS)) {
 +   u64 *aesctx2 = (u64 *)areq-info + 1;
 +
 +   if (*aesctx2 != 0) {
 +   dev_err(ctx-dev,
 +   IV length limited to the first 8 bytes.);
 +   return ERR_PTR(-EINVAL);
 +   }
 +
 +   /* Fixed sized sector */
 +   *aesctx2 = cpu_to_be64(1  SECTOR_SHIFT);
 +   }
 
 
 This approach causes the tcrypt tests to fail because tcrypt sets all
 16 bytes of the IV to 0xff.  I think returning an error is the right
 approach for the talitos module, but it would be nice if tcrypt still
 worked.  Should tcrypt just set the IV bytes to 0 instead of 0xff?
 Isn't one IV just as good as another?  I think adding exceptions to
 the tcrypt code would be ugly, but maybe one should be made for XTS
 since the standard dictates that the IV should be plain or plain64?

AFAICT xts-aes standard does not mandate for plain or plain64.
The requirements are the following (below IV = tweak value, sector =
data unit):
-IV size: 16 bytes
-IV format: little endian byte array
-IV values: non-negative; consecutive IV values for consecutive sectors

In practice, an 8-byte IV should be enough to represent the sector index
even for large capacity storage devices.
However, dm-crypt has support for a user-provided iv_offset that is
added to the sector index: IV = sector_index + iv_offset.
While in most of the cases user would choose iv_offset = 0, in theory
anything is possible.

IMHO the correct approach would be to use a fallback tfm that would
handle all the requests with IVs  8 bytes.
We can take this off-list if you prefer.

Horia


--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/2] crypto: talitos: Add AES-XTS mode

2015-03-13 Thread Martin Hicks 
Hi Horia,

On Wed, Mar 11, 2015 at 11:48 AM, Horia Geantă
horia.gea...@freescale.com wrote:

 While here: note that xts-talitos supports only two key lengths - 256
 and 512 bits. There are tcrypt speed tests that check also for 384-bit
 keys (which is out-of-spec, but still...), leading to a Key Size Error
 - see below (KSE bit in AESU Interrupt Status Register is set)

Ok.  I've limited the keysize to 32 or 64 bytes for AES-XTS in the
talitos driver.

This was my first experiments with the tcrypt module.  It also brought
up another issue related to the IV limitations of this hardware.  The
latest patch that I have returns an error when there is a non-zero
value in the second 8 bytes of the IV:

+   /*
+* AES-XTS uses the first two AES Context registers for:
+*
+* Register 1:   Sector Number (Little Endian)
+* Register 2:   Sector Size   (Big Endian)
+*
+* Whereas AES-CBC uses registers 1/2 as a 16-byte IV.
+*/
+   if ((ctx-desc_hdr_template 
+(DESC_HDR_SEL0_MASK | DESC_HDR_MODE0_MASK)) ==
+(DESC_HDR_SEL0_AESU | DESC_HDR_MODE0_AESU_XTS)) {
+   u64 *aesctx2 = (u64 *)areq-info + 1;
+
+   if (*aesctx2 != 0) {
+   dev_err(ctx-dev,
+   IV length limited to the first 8 bytes.);
+   return ERR_PTR(-EINVAL);
+   }
+
+   /* Fixed sized sector */
+   *aesctx2 = cpu_to_be64(1  SECTOR_SHIFT);
+   }


This approach causes the tcrypt tests to fail because tcrypt sets all
16 bytes of the IV to 0xff.  I think returning an error is the right
approach for the talitos module, but it would be nice if tcrypt still
worked.  Should tcrypt just set the IV bytes to 0 instead of 0xff?
Isn't one IV just as good as another?  I think adding exceptions to
the tcrypt code would be ugly, but maybe one should be made for XTS
since the standard dictates that the IV should be plain or plain64?

Thanks,
mh

-- 
Martin Hicks P.Eng.  | m...@bork.org
Bork Consulting Inc. |   +1 (613) 266-2296
--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/2] crypto: talitos: Add AES-XTS mode

2015-03-11 Thread Horia Geantă 
On 3/9/2015 5:08 PM, Martin Hicks wrote:
 On Mon, Mar 9, 2015 at 6:16 AM, Horia Geantă horia.gea...@freescale.com 
 wrote:
 On 3/3/2015 7:44 PM, Martin Hicks wrote:
 On Tue, Mar 3, 2015 at 10:44 AM, Horia Geantă
 horia.gea...@freescale.com wrote:

 For talitos, there are two cases:

 1. request data size is = data unit / sector size
 talitos can handle any IV / tweak scheme

 2. request data size  sector size
 since talitos internally generates the IV for the next sector by
 incrementing the previous IV, only IV schemes that allocate consecutive
 IV to consecutive sectors will function correctly.


 it's not clear to me that #1 is right.  I guess it could be, but the
 IV length would be limited to 8 bytes.

 Yes, there's a limitation in talitos wrt. XTS IV / tweak size - it's up
 to 8 bytes.
 So I guess ESSIV won't work with talitos-xts, since the encrypted IV
 output is 16 bytes.
 But as previously said, ESSIV breaks the XTS standard requirement for
 having a consecutive IV for consecutive blocks. ESSIV should really be
 used only with disk-level encryption schemes that require an
 unpredictable IV.
 
 Ok.  I'll verify that the second half of the IV is zeroed.
 
 One last thing that I'm not sure of is what string to place in
 cra_ablkcipher.geniv field.   eseqiv seems wrong if plain/plain64
 are the IVs that XTS is designed for.

Right. But since currently dm-crypt does not use .givencrypt and deals
with IV generation by itself, we're safe.
When dm-crypt IV generation will be moved to crypto, we'll have to
revisit this.

While here: note that xts-talitos supports only two key lengths - 256
and 512 bits. There are tcrypt speed tests that check also for 384-bit
keys (which is out-of-spec, but still...), leading to a Key Size Error
- see below (KSE bit in AESU Interrupt Status Register is set)

testing speed of async xts(aes) (xts-aes-talitos) encryption
[...]
test 5 (384 bit key, 16 byte blocks):
talitos ffe3.crypto: CDPR is NULL, giving up search for offending
descriptor
talitos ffe3.crypto: AESUISR 0x_0200
talitos ffe3.crypto: DESCBUF 0x64300011_
talitos ffe3.crypto: DESCBUF 0x_
talitos ffe3.crypto: DESCBUF 0x0010_
talitos ffe3.crypto: DESCBUF 0x0030_
talitos ffe3.crypto: DESCBUF 0x0010_
talitos ffe3.crypto: DESCBUF 0x0010_
talitos ffe3.crypto: DESCBUF 0x0010_
talitos ffe3.crypto: DESCBUF 0x_
encryption() failed flags=0

So for xts, driver must enforce 256/512 bit key lengths and return
CRYPTO_TFM_RES_BAD_KEY_LEN in all other cases.
Or a SW fallback could be used for the other cases, but I don't think
it's worth the effort since these are non-standard.

Horia


--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/2] crypto: talitos: Add AES-XTS mode

2015-03-09 Thread Martin Hicks 
On Mon, Mar 9, 2015 at 6:16 AM, Horia Geantă horia.gea...@freescale.com wrote:
 On 3/3/2015 7:44 PM, Martin Hicks wrote:
 On Tue, Mar 3, 2015 at 10:44 AM, Horia Geantă
 horia.gea...@freescale.com wrote:

 For talitos, there are two cases:

 1. request data size is = data unit / sector size
 talitos can handle any IV / tweak scheme

 2. request data size  sector size
 since talitos internally generates the IV for the next sector by
 incrementing the previous IV, only IV schemes that allocate consecutive
 IV to consecutive sectors will function correctly.


 it's not clear to me that #1 is right.  I guess it could be, but the
 IV length would be limited to 8 bytes.

 Yes, there's a limitation in talitos wrt. XTS IV / tweak size - it's up
 to 8 bytes.
 So I guess ESSIV won't work with talitos-xts, since the encrypted IV
 output is 16 bytes.
 But as previously said, ESSIV breaks the XTS standard requirement for
 having a consecutive IV for consecutive blocks. ESSIV should really be
 used only with disk-level encryption schemes that require an
 unpredictable IV.

Ok.  I'll verify that the second half of the IV is zeroed.

One last thing that I'm not sure of is what string to place in
cra_ablkcipher.geniv field.   eseqiv seems wrong if plain/plain64
are the IVs that XTS is designed for.

Thanks,
mh

-- 
Martin Hicks P.Eng.  | m...@bork.org
Bork Consulting Inc. |   +1 (613) 266-2296
--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/2] crypto: talitos: Add AES-XTS mode

2015-03-09 Thread Horia Geantă 
On 3/3/2015 7:44 PM, Martin Hicks wrote:
 On Tue, Mar 3, 2015 at 10:44 AM, Horia Geantă
 horia.gea...@freescale.com wrote:
 On 3/3/2015 12:09 AM, Martin Hicks wrote:

 On Mon, Mar 02, 2015 at 03:37:28PM +0100, Milan Broz wrote:

 If crypto API allows to encrypt more sectors in one run
 (handling IV internally) dmcrypt can be modified of course.

 But do not forget we can use another IV (not only sequential number)
 e.g. ESSIV with XTS as well (even if it doesn't make much sense, some 
 people
 are using it).

 Interesting, I'd not considered using XTS with an IV other than plain/64.
 The talitos hardware would not support aes/xts in any mode other than
 plain/plain64 I don't think...Although perhaps you could push in an 8-byte
 IV and the hardware would interpret it as the sector #.


 For talitos, there are two cases:

 1. request data size is = data unit / sector size
 talitos can handle any IV / tweak scheme

 2. request data size  sector size
 since talitos internally generates the IV for the next sector by
 incrementing the previous IV, only IV schemes that allocate consecutive
 IV to consecutive sectors will function correctly.

 
 it's not clear to me that #1 is right.  I guess it could be, but the
 IV length would be limited to 8 bytes.

Yes, there's a limitation in talitos wrt. XTS IV / tweak size - it's up
to 8 bytes.
So I guess ESSIV won't work with talitos-xts, since the encrypted IV
output is 16 bytes.
But as previously said, ESSIV breaks the XTS standard requirement for
having a consecutive IV for consecutive blocks. ESSIV should really be
used only with disk-level encryption schemes that require an
unpredictable IV.

 
 This also points out that claiming that the XTS IV size is 16 bytes,
 as my current patch does, could be problematic.  It's handy because
 the first 8 bytes should contain a plain64 sector #, and the second
 u64 can be used to encode the sector size but it would be a mistake
 for someone to use the second 8 bytes for the rest of a 16byte IV.

XTS IV *is* 16 bytes. The fact that xts-talitos can handle only 8 bytes
is a problem indeed, but for plain and plain64 should not matter.

Horia


--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/2] crypto: talitos: Add AES-XTS mode

2015-03-03 Thread Horia Geantă 
On 3/3/2015 12:09 AM, Martin Hicks wrote:
 
 On Mon, Mar 02, 2015 at 03:37:28PM +0100, Milan Broz wrote:

 If crypto API allows to encrypt more sectors in one run
 (handling IV internally) dmcrypt can be modified of course.

 But do not forget we can use another IV (not only sequential number)
 e.g. ESSIV with XTS as well (even if it doesn't make much sense, some people
 are using it).
 
 Interesting, I'd not considered using XTS with an IV other than plain/64.
 The talitos hardware would not support aes/xts in any mode other than
 plain/plain64 I don't think...Although perhaps you could push in an 8-byte
 IV and the hardware would interpret it as the sector #.
 

For talitos, there are two cases:

1. request data size is = data unit / sector size
talitos can handle any IV / tweak scheme

2. request data size  sector size
since talitos internally generates the IV for the next sector by
incrementing the previous IV, only IV schemes that allocate consecutive
IV to consecutive sectors will function correctly.

Let's not forget what XTS standard says about IVs / tweak values:
- each data unit (sector in this case) is assigned a non-negative tweak
value and
- tweak values are assigned *consecutively*, starting from an arbitrary
non-negative value
- there's no requirement for tweak values to be unpredictable

Thus, in theory ESSIV is not supposed to be used with XTS mode: the IVs
for consecutive sectors are not consecutive values.
In practice, as Milan said, the combination is sometimes used. It
functions correctly in SW (and also in talitos as long as req. data size
= sector size).

 Maybe the following question would be if the dmcrypt sector IV algorithms
 should moved into crypto API as well.
 (But because I misused dmcrypt IVs hooks for some additional operations
 for loopAES and old Truecrypt CBC mode, it is not so simple...)
 
 Speaking again with talitos in mind, there would be no advantage for this
 hardware.  Although larger requests are possible only a single IV can be
 provided per request, so for algorithms like AES-CBC and dm-crypt 512byte IOs
 are the only option (short of switching to 4kB block size).

Right, as explained above talitos does what the XTS mode standard
mandates. So it won't work properly in case of cbc-aes:essiv with
request sizes larger than sector size.

Still, in SW at least, XTS could be improved to process more sectors in
one shot, regardless of the IV scheme used - as long as there's a
IV.next() function and both data size and sector size are known.

Horia

--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/2] crypto: talitos: Add AES-XTS mode

2015-03-03 Thread Martin Hicks 
On Tue, Mar 3, 2015 at 10:44 AM, Horia Geantă
horia.gea...@freescale.com wrote:
 On 3/3/2015 12:09 AM, Martin Hicks wrote:

 On Mon, Mar 02, 2015 at 03:37:28PM +0100, Milan Broz wrote:

 If crypto API allows to encrypt more sectors in one run
 (handling IV internally) dmcrypt can be modified of course.

 But do not forget we can use another IV (not only sequential number)
 e.g. ESSIV with XTS as well (even if it doesn't make much sense, some people
 are using it).

 Interesting, I'd not considered using XTS with an IV other than plain/64.
 The talitos hardware would not support aes/xts in any mode other than
 plain/plain64 I don't think...Although perhaps you could push in an 8-byte
 IV and the hardware would interpret it as the sector #.


 For talitos, there are two cases:

 1. request data size is = data unit / sector size
 talitos can handle any IV / tweak scheme

 2. request data size  sector size
 since talitos internally generates the IV for the next sector by
 incrementing the previous IV, only IV schemes that allocate consecutive
 IV to consecutive sectors will function correctly.


it's not clear to me that #1 is right.  I guess it could be, but the
IV length would be limited to 8 bytes.

This also points out that claiming that the XTS IV size is 16 bytes,
as my current patch does, could be problematic.  It's handy because
the first 8 bytes should contain a plain64 sector #, and the second
u64 can be used to encode the sector size but it would be a mistake
for someone to use the second 8 bytes for the rest of a 16byte IV.

mh

-- 
Martin Hicks P.Eng.  | m...@bork.org
Bork Consulting Inc. |   +1 (613) 266-2296
--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/2] crypto: talitos: Add AES-XTS mode

2015-03-02 Thread Martin Hicks 

On Mon, Mar 02, 2015 at 03:37:28PM +0100, Milan Broz wrote:
 
 If crypto API allows to encrypt more sectors in one run
 (handling IV internally) dmcrypt can be modified of course.
 
 But do not forget we can use another IV (not only sequential number)
 e.g. ESSIV with XTS as well (even if it doesn't make much sense, some people
 are using it).

Interesting, I'd not considered using XTS with an IV other than plain/64.
The talitos hardware would not support aes/xts in any mode other than
plain/plain64 I don't think...Although perhaps you could push in an 8-byte
IV and the hardware would interpret it as the sector #.

 Maybe the following question would be if the dmcrypt sector IV algorithms
 should moved into crypto API as well.
 (But because I misused dmcrypt IVs hooks for some additional operations
 for loopAES and old Truecrypt CBC mode, it is not so simple...)

Speaking again with talitos in mind, there would be no advantage for this
hardware.  Although larger requests are possible only a single IV can be
provided per request, so for algorithms like AES-CBC and dm-crypt 512byte IOs
are the only option (short of switching to 4kB block size).

mh

-- 
Martin Hicks P.Eng.|  m...@bork.org
Bork Consulting Inc.   |  +1 (613) 266-2296
--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/2] crypto: talitos: Add AES-XTS mode

2015-03-02 Thread Martin Hicks 
On Mon, Mar 02, 2015 at 03:25:56PM +0200, Horia Geantă wrote:
 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
  (1SECTOR_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...

Right.  Additionally, there may be some requirement for the encryption
implementation to broadcast the maximum size that can be handled in a single
request.  For example Talitos could handle XTS encrypt/decrypt requests of
up to 64kB (regardless of the block device's sector size).

 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 found this last week, and used it as a starting point for some testing.  I
modified it to keep the underlying sector size of the dm-crypt mapping as
512byte, but allowed the code to combine requests in IOs up to 4kB.  Doing
greater request sizes would require allocating additional pages...I plan to
implement that to see how much extra performance can be squeezed out.

patch below...

With regards to performance, with my low-powered Freescale P1022 board, I see
performance numbers like this on ext4, as measured by bonnie++.

Write (MB/s)Read (MB/s)
Unencrypted 140 176
aes-xts-plain64 512b113 115
aes-xts-plain64 4kB 71  56

The more detailed bonnie++ output is here:
http://www.bork.org/~mort/dm-crypt-enc-blksize.html

The larger IO sizes is a huge win for this board.

The patch I'm using to send IOs up to 4kB to talitos follows.

Thanks,
mh


diff --git a/drivers/md/dm-crypt.c b/drivers/md/dm-crypt.c
index 08981be..88e95b5 100644
--- a/drivers/md/dm-crypt.c
+++ b/drivers/md/dm-crypt.c
@@ -42,6 +42,7 @@ struct convert_context {
struct bvec_iter iter_out;
sector_t cc_sector;
atomic_t cc_pending;
+   unsigned int block_size;
struct ablkcipher_request *req;
 };
 
@@ -142,6 +143,8 @@ struct crypt_config {
sector_t iv_offset;
unsigned int iv_size;
 
+   unsigned int block_size;
+
/* ESSIV: struct crypto_cipher *essiv_tfm */
void *iv_private;
struct crypto_ablkcipher **tfms;
@@ -801,10 +804,17 @@ static void crypt_convert_init(struct crypt_config *cc,
 {
ctx-bio_in = bio_in;
ctx-bio_out = bio_out;
-   if (bio_in)
+   ctx-block_size = 0;
+   if (bio_in) {
ctx-iter_in = bio_in-bi_iter;
-   if (bio_out)
+   ctx-block_size = max(ctx-block_size, bio_cur_bytes(bio_in));
+   }
+   if (bio_out) {
ctx-iter_out = bio_out-bi_iter;
+   ctx-block_size = max(ctx-block_size, bio_cur_bytes(bio_out));
+   }
+   if (ctx-block_size  cc-block_size)
+   ctx-block_size = cc-block_size;
ctx-cc_sector = sector + cc-iv_offset;
init_completion(ctx-restart);
 }
@@ -844,15 +854,15 @@ static int crypt_convert_block(struct crypt_config *cc,
dmreq-iv_sector = ctx-cc_sector;
dmreq-ctx = ctx;
sg_init_table(dmreq-sg_in, 1);
-

Re: [PATCH 0/2] crypto: talitos: Add AES-XTS mode

2015-03-02 Thread Martin Hicks 
On Mon, Mar 02, 2015 at 04:44:19PM -0500, Martin Hicks wrote:
 
   Write (MB/s)Read (MB/s)
 Unencrypted   140 176
 aes-xts-plain64 512b  113 115
 aes-xts-plain64 4kB   71  56

I got the two AES lines backwards.  Sorry about that.

mh

-- 
Martin Hicks P.Eng.|  m...@bork.org
Bork Consulting Inc.   |  +1 (613) 266-2296
--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/2] crypto: talitos: Add AES-XTS mode

2015-03-02 Thread Milan Broz 
On 03/02/2015 02:25 PM, Horia Geantă wrote:
 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
 (1SECTOR_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.

There was no follow-up but the idea is not yet abandoned :-)

Dmcrypt will always use sector as a minimal unit
(and I believe sectors will by always multiple of block size so
no need for ciphertext stealing in XTS.)

For now, dmcrypt always use 512 bytes sector size.

If crypto API allows to encrypt more sectors in one run
(handling IV internally) dmcrypt can be modified of course.

But do not forget we can use another IV (not only sequential number)
e.g. ESSIV with XTS as well (even if it doesn't make much sense, some people
are using it).

Maybe the following question would be if the dmcrypt sector IV algorithms
should moved into crypto API as well.
(But because I misused dmcrypt IVs hooks for some additional operations
for loopAES and old Truecrypt CBC mode, it is not so simple...)

Milan
--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/2] crypto: talitos: Add AES-XTS mode

2015-03-02 Thread Horia Geantă 
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
 (1SECTOR_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(-)
 


--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html