Re: ctr(aes) broken in CAAM driver

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 5/15/2019 4:22 PM, Sascha Hauer wrote:
> Hi Fabio,
> 
> On Wed, May 15, 2019 at 10:17:19AM -0300, Fabio Estevam wrote:
>> Hi Sascha,
>>
>> On Wed, May 15, 2019 at 10:09 AM Sascha Hauer <s.hauer@xxxxxxxxxxxxxx> wrote:
>>>
>>> Hi,
>>>
>>> ctr(aes) is broken in current kernel (v5.1+). It may have been broken
>>> for longer, but the crypto tests now check for a correct output IV. The
>>> testmgr answers with:
>>>
>>> alg: skcipher: ctr-aes-caam encryption test failed (wrong output IV) on test vector 0, cfg="in-place"
>>>
>>> output IV is this, which is the last 16 bytes of the encrypted message:
>>> 00000000: 1e 03 1d da 2f be 03 d1 79 21 70 a0 f3 00 9c ee
>>>
>>> It should look like this instead, which is input IV + 4:
>>> 00000000: f0 f1 f2 f3 f4 f5 f6 f7 f8 f9 fa fb fc fd ff 03
>>>
>>> I have no idea how to fix this as I don't know how to get the output IV
>>> back from the CAAM. Any ideas?
>>
>> Is this problem similar to this one?
>> https://www.mail-archive.com/linux-crypto@xxxxxxxxxxxxxxx/msg37512.html
> 
> Different algo, different hardware, but yes, it seems to be the same
> type of failure.
> 
For talitos, the problem is the lack of IV update.

For caam, the problem is incorrect IV update (output IV is equal to last
ciphertext block, which is correect for cbc, but not for ctr mode).

I am working at a fix, but it takes longer since I would like to program the
accelerator to the save the IV (and not do counter increment in SW, which
created problems for many other implementations).

Regards,
Horia




[Index of Archives]     [Kernel]     [Gnu Classpath]     [Gnu Crypto]     [DM Crypt]     [Netfilter]     [Bugtraq]

  Powered by Linux