Re: [PATCH 0/2] crypto: talitos: Add AES-XTS mode
On 3/13/2015 4:08 PM, Martin Hicks wrote: > Hi Horia, > > On Wed, Mar 11, 2015 at 11:48 AM, Horia Geantă > 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
Hi Horia, On Wed, Mar 11, 2015 at 11:48 AM, Horia Geantă 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
On 3/9/2015 5:08 PM, Martin Hicks wrote: > On Mon, Mar 9, 2015 at 6:16 AM, Horia Geantă > wrote: >> On 3/3/2015 7:44 PM, Martin Hicks wrote: >>> On Tue, Mar 3, 2015 at 10:44 AM, Horia Geantă >>> 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
On Mon, Mar 9, 2015 at 6:16 AM, Horia Geantă wrote: > On 3/3/2015 7:44 PM, Martin Hicks wrote: >> On Tue, Mar 3, 2015 at 10:44 AM, Horia Geantă >> 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
On 3/3/2015 7:44 PM, Martin Hicks wrote: > On Tue, Mar 3, 2015 at 10:44 AM, Horia Geantă > 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
On Tue, Mar 3, 2015 at 10:44 AM, Horia Geantă 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
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
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
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
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 > > (1< > 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_ta
Re: [PATCH 0/2] crypto: talitos: Add AES-XTS mode
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 >> (1<> 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
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 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
[PATCH 0/2] crypto: talitos: Add AES-XTS mode
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