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 [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
