Re: [RFC] Unaligned CTR mode tests in crypto/testmgr.h

[Joel Fernandes <joelf@ti.com>]

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