From: Joel Fernandes Subject: Re: [RFC] Unaligned CTR mode tests in crypto/testmgr.h Date: Wed, 30 Oct 2013 16:06:37 -0500 Message-ID: <527174DD.1010504@ti.com> References: <52704EAB.5000308@ti.com> <5270E903.3020502@iki.fi> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Cc: Linux Crypto Mailing List To: Jussi Kivilinna Return-path: Received: from comal.ext.ti.com ([198.47.26.152]:51891 "EHLO comal.ext.ti.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752343Ab3J3VGy (ORCPT ); Wed, 30 Oct 2013 17:06:54 -0400 In-Reply-To: <5270E903.3020502@iki.fi> Sender: linux-crypto-owner@vger.kernel.org List-ID: 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