Hi:
The cbc-aes-s390 algorithm incorrectly places the IV in the tfm
data structure. As the tfm is shared between multiple threads,
this introduces a possibility of data corruption.
This patch fixes this by moving the parameter block containing
the IV and key onto the stack (the block is 48 bytes
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
> -Original Message-
> From: Herbert Xu [mailto:herb...@gondor.hengli.com.au]
> Sent: Tuesday, October 29, 2013 8:54 PM
> To: Fernandes, Joel
> Cc: jussi.kivili...@mbnet.fi; linux-crypto@vger.kernel.org
> Subject: Re: [RFC] Unaligned CTR mode tests in crypto/testmgr.h
>
> Joel Fernandes
Theodore Ts'o wrote:
> Fundamentally, what worries me about this scheme (actually, causes the
> hair on the back of my neck to rise up on end) is this statement in
> your documentation[1]:
>
>When looking at the sequence of time deltas gathered
>during testing [D] , no pattern can be dete
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 i
