* [RFC] Unaligned CTR mode tests in crypto/testmgr.h
@ 2013-10-30 0:11 Joel Fernandes
2013-10-30 1:54 ` Herbert Xu
2013-10-30 11:09 ` Jussi Kivilinna
0 siblings, 2 replies; 6+ messages in thread
From: Joel Fernandes @ 2013-10-30 0:11 UTC (permalink / raw)
To: jussi.kivilinna; +Cc: Linux Crypto Mailing List
Hi,
Some tests such as test 5 in AES CTR mode in crypto/testmgr.h have a unaligned
input buffer size such as 499 which is not aligned to any > 0 power of 2.
Due to this, omap-aes driver, and I think atmel-aes too error out when
encryption is requested for these buffers.
pr_err("request size is not exact amount of AES blocks\n") or a similar message.
Is this failure considered a bug? How do we fix it?
How were the result output vectors generated, did you use 0 padding? Do we 0 pad
the inputs to align in these cases to get correct results?
thanks,
-Joel
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: [RFC] Unaligned CTR mode tests in crypto/testmgr.h 2013-10-30 0:11 [RFC] Unaligned CTR mode tests in crypto/testmgr.h Joel Fernandes @ 2013-10-30 1:54 ` Herbert Xu 2013-10-30 18:34 ` Fernandes, Joel 2013-10-30 11:09 ` Jussi Kivilinna 1 sibling, 1 reply; 6+ messages in thread From: Herbert Xu @ 2013-10-30 1:54 UTC (permalink / raw) To: Joel Fernandes; +Cc: jussi.kivilinna, linux-crypto Joel Fernandes <joelf@ti.com> wrote: > Hi, > > Some tests such as test 5 in AES CTR mode in crypto/testmgr.h have a unaligned > input buffer size such as 499 which is not aligned to any > 0 power of 2. > > Due to this, omap-aes driver, and I think atmel-aes too error out when > encryption is requested for these buffers. > > pr_err("request size is not exact amount of AES blocks\n") or a similar message. > > Is this failure considered a bug? How do we fix it? Set your alignmask correctly and the crypto API will align the input buffer for you. Cheers, -- Email: Herbert Xu <herbert@gondor.apana.org.au> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt ^ permalink raw reply [flat|nested] 6+ messages in thread
* RE: [RFC] Unaligned CTR mode tests in crypto/testmgr.h 2013-10-30 1:54 ` Herbert Xu @ 2013-10-30 18:34 ` Fernandes, Joel 0 siblings, 0 replies; 6+ messages in thread From: Fernandes, Joel @ 2013-10-30 18:34 UTC (permalink / raw) To: Herbert Xu; +Cc: jussi.kivilinna@mbnet.fi, linux-crypto@vger.kernel.org > -----Original Message----- > From: Herbert Xu [mailto:herbert@gondor.hengli.com.au] > Sent: Tuesday, October 29, 2013 8:54 PM > To: Fernandes, Joel > Cc: jussi.kivilinna@mbnet.fi; linux-crypto@vger.kernel.org > Subject: Re: [RFC] Unaligned CTR mode tests in crypto/testmgr.h > > Joel Fernandes <joelf@ti.com> wrote: > > Hi, > > > > Some tests such as test 5 in AES CTR mode in crypto/testmgr.h have a > > unaligned input buffer size such as 499 which is not aligned to any > 0 > power of 2. > > > > Due to this, omap-aes driver, and I think atmel-aes too error out when > > encryption is requested for these buffers. > > > > pr_err("request size is not exact amount of AES blocks\n") or a similar > message. > > > > Is this failure considered a bug? How do we fix it? > > Set your alignmask correctly and the crypto API will align the input buffer for > you. Thanks! I'll try this today and follow up with a patch if I can get past the error. Regards, -Joel ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [RFC] Unaligned CTR mode tests in crypto/testmgr.h 2013-10-30 0:11 [RFC] Unaligned CTR mode tests in crypto/testmgr.h Joel Fernandes 2013-10-30 1:54 ` Herbert Xu @ 2013-10-30 11:09 ` Jussi Kivilinna 2013-10-30 21:06 ` Joel Fernandes 1 sibling, 1 reply; 6+ messages in thread From: Jussi Kivilinna @ 2013-10-30 11:09 UTC (permalink / raw) To: Joel Fernandes; +Cc: Linux Crypto Mailing List On 30.10.2013 02:11, Joel Fernandes wrote: > Hi, > > Some tests such as test 5 in AES CTR mode in crypto/testmgr.h have a unaligned > input buffer size such as 499 which is not aligned to any > 0 power of 2. > > Due to this, omap-aes driver, and I think atmel-aes too error out when > encryption is requested for these buffers. > > pr_err("request size is not exact amount of AES blocks\n") or a similar message. > > Is this failure considered a bug? How do we fix it? Counter mode turns block cipher into stream cipher and implementation must handle buffer lengths that do not match the block size of underlying block cipher. > > How were the result output vectors generated, did you use 0 padding? Do we 0 pad > the inputs to align in these cases to get correct results? See crypto/ctr.c:crypto_ctr_crypt_final() how to handle trailing bytes when 'buflen % AES_BLOCK_SIZE != 0'. Basically, you encrypt the last counter block to generate the last keystream block and xor only the 'buflen % AES_BLOCK_SIZE' bytes of last keystream block with the tail bytes of source buffer: key_last[0..15] = ENC(K, counter[0..15]); dst_last[0..trailbytes-1] = src_last[0..trailbytes-1] ^ key_last[0..trailbytes-1]; /* key_last[trailbytes..15] discarded. */ Or if you want to use hardware that only does block-size aligned CTR encryption, you can pad input to block size aligned length, do encryption, and then discard those padding bytes after encryption: src_padded[0..trailbytes-1] = src_last[0..trailbytes-1] src_padded[trailbytes..15] = /* don't care, can be anything/uninitialized */ src_padded[0..15] = ENC_HW_CTR(src_padded[0..15]); dst_last[0..trailbytes-1] = src_padded[0..trailbytes-1]; /* src_padded[trailbytes..15] discarded. */ Here, ENC_HW_CTR(in) internally does: keystream[0..15] = ENC(K, counter[0..15]); INC_CTR(counter); out[0..15] = in[0..15] ^ keystream[0..15]; -Jussi > > thanks, > > -Joel > -- > To unsubscribe from this list: send the line "unsubscribe linux-crypto" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [RFC] Unaligned CTR mode tests in crypto/testmgr.h 2013-10-30 11:09 ` Jussi Kivilinna @ 2013-10-30 21:06 ` Joel Fernandes 2013-10-31 8:40 ` Jussi Kivilinna 0 siblings, 1 reply; 6+ messages in thread From: Joel Fernandes @ 2013-10-30 21:06 UTC (permalink / raw) To: Jussi Kivilinna; +Cc: Linux Crypto Mailing List On 10/30/2013 06:09 AM, Jussi Kivilinna wrote: > On 30.10.2013 02:11, Joel Fernandes wrote: >> Hi, >> >> Some tests such as test 5 in AES CTR mode in crypto/testmgr.h have a unaligned >> input buffer size such as 499 which is not aligned to any > 0 power of 2. >> >> Due to this, omap-aes driver, and I think atmel-aes too error out when >> encryption is requested for these buffers. >> >> pr_err("request size is not exact amount of AES blocks\n") or a similar message. >> >> Is this failure considered a bug? How do we fix it? > > Counter mode turns block cipher into stream cipher and implementation must handle > buffer lengths that do not match the block size of underlying block cipher. > >> >> How were the result output vectors generated, did you use 0 padding? Do we 0 pad >> the inputs to align in these cases to get correct results? > > See crypto/ctr.c:crypto_ctr_crypt_final() how to handle trailing bytes when > 'buflen % AES_BLOCK_SIZE != 0'. > > Basically, you encrypt the last counter block to generate the last keystream > block and xor only the 'buflen % AES_BLOCK_SIZE' bytes of last keystream block > with the tail bytes of source buffer: > > key_last[0..15] = ENC(K, counter[0..15]); > dst_last[0..trailbytes-1] = src_last[0..trailbytes-1] ^ key_last[0..trailbytes-1]; > /* key_last[trailbytes..15] discarded. */ > > Or if you want to use hardware that only does block-size aligned CTR encryption, > you can pad input to block size aligned length, do encryption, and then discard > those padding bytes after encryption: > > src_padded[0..trailbytes-1] = src_last[0..trailbytes-1] > src_padded[trailbytes..15] = /* don't care, can be anything/uninitialized */ > src_padded[0..15] = ENC_HW_CTR(src_padded[0..15]); > dst_last[0..trailbytes-1] = src_padded[0..trailbytes-1]; > /* src_padded[trailbytes..15] discarded. */ > > Here, ENC_HW_CTR(in) internally does: > keystream[0..15] = ENC(K, counter[0..15]); INC_CTR(counter); > out[0..15] = in[0..15] ^ keystream[0..15]; > Thanks, I'll try that. Just one question- is it safe to assume the output buffer (req->dst) is capable of holding those many bytes? In your algorithm above, we're assuming here without allocating explicitly that the output buffer passed to the driver has trailbytes..15 available. Because otherwise we are in danger of introducing a memory leak, if we just assume they are available in the output buffer. That said, I don't want to allocate new buffer in the driver and then do copying of encrypted data back into the output buffer. Because I did lot of hard work to get rid of such code as it is slower. thanks, -Joel ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [RFC] Unaligned CTR mode tests in crypto/testmgr.h 2013-10-30 21:06 ` Joel Fernandes @ 2013-10-31 8:40 ` Jussi Kivilinna 0 siblings, 0 replies; 6+ messages in thread From: Jussi Kivilinna @ 2013-10-31 8:40 UTC (permalink / raw) To: Joel Fernandes; +Cc: Linux Crypto Mailing List On 30.10.2013 23:06, Joel Fernandes wrote: > On 10/30/2013 06:09 AM, Jussi Kivilinna wrote: >> On 30.10.2013 02:11, Joel Fernandes wrote: >>> Hi, >>> >>> Some tests such as test 5 in AES CTR mode in crypto/testmgr.h have a unaligned >>> input buffer size such as 499 which is not aligned to any > 0 power of 2. >>> >>> Due to this, omap-aes driver, and I think atmel-aes too error out when >>> encryption is requested for these buffers. >>> >>> pr_err("request size is not exact amount of AES blocks\n") or a similar message. >>> >>> Is this failure considered a bug? How do we fix it? >> >> Counter mode turns block cipher into stream cipher and implementation must handle >> buffer lengths that do not match the block size of underlying block cipher. >> >>> >>> How were the result output vectors generated, did you use 0 padding? Do we 0 pad >>> the inputs to align in these cases to get correct results? >> >> See crypto/ctr.c:crypto_ctr_crypt_final() how to handle trailing bytes when >> 'buflen % AES_BLOCK_SIZE != 0'. >> >> Basically, you encrypt the last counter block to generate the last keystream >> block and xor only the 'buflen % AES_BLOCK_SIZE' bytes of last keystream block >> with the tail bytes of source buffer: >> >> key_last[0..15] = ENC(K, counter[0..15]); >> dst_last[0..trailbytes-1] = src_last[0..trailbytes-1] ^ key_last[0..trailbytes-1]; >> /* key_last[trailbytes..15] discarded. */ >> >> Or if you want to use hardware that only does block-size aligned CTR encryption, >> you can pad input to block size aligned length, do encryption, and then discard >> those padding bytes after encryption: >> >> src_padded[0..trailbytes-1] = src_last[0..trailbytes-1] >> src_padded[trailbytes..15] = /* don't care, can be anything/uninitialized */ >> src_padded[0..15] = ENC_HW_CTR(src_padded[0..15]); >> dst_last[0..trailbytes-1] = src_padded[0..trailbytes-1]; >> /* src_padded[trailbytes..15] discarded. */ >> >> Here, ENC_HW_CTR(in) internally does: >> keystream[0..15] = ENC(K, counter[0..15]); INC_CTR(counter); >> out[0..15] = in[0..15] ^ keystream[0..15]; >> > > Thanks, I'll try that. Just one question- is it safe to assume the output buffer > (req->dst) is capable of holding those many bytes? > > In your algorithm above, we're assuming here without allocating explicitly that > the output buffer passed to the driver has trailbytes..15 available. Because > otherwise we are in danger of introducing a memory leak, if we just assume they > are available in the output buffer. In above example, I meant src_padded being temporary block-sized buffer to handle the last trailing bytes. I don't think you can assume that req->dst would have this extra space. > > That said, I don't want to allocate new buffer in the driver and then do copying > of encrypted data back into the output buffer. Because I did lot of hard work to > get rid of such code as it is slower. > Could you handle first 'buflen - buflen % blocksize' bytes as done currently without extra copies and then handle the trailing bytes separately? -Jussi > thanks, > > -Joel > > -- > To unsubscribe from this list: send the line "unsubscribe linux-crypto" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2013-10-31 8:41 UTC | newest] Thread overview: 6+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2013-10-30 0:11 [RFC] Unaligned CTR mode tests in crypto/testmgr.h Joel Fernandes 2013-10-30 1:54 ` Herbert Xu 2013-10-30 18:34 ` Fernandes, Joel 2013-10-30 11:09 ` Jussi Kivilinna 2013-10-30 21:06 ` Joel Fernandes 2013-10-31 8:40 ` Jussi Kivilinna
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).