Re: aes_expandkey giving wrong expanded keys over crypto_aes_expand_key(older deprecated implementation under aes_generic)

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

 




On 10/12/19 3:37 pm, Ard Biesheuvel wrote:
> On Tue, 10 Dec 2019 at 11:06, Keerthy <j-keerthy@xxxxxx> wrote:
>>
>>
>>
>> On 10/12/19 3:31 pm, Ard Biesheuvel wrote:
>>> Hello Keerthy,
>>>
>>> On Tue, 10 Dec 2019 at 10:35, Keerthy <j-keerthy@xxxxxx> wrote:
>>>>
>>>> Hi Ard,
>>>>
>>>> I am not sure if am the first one to report this. It seems like
>>>> aes_expandkey is giving me different expansion over what i get with the
>>>> older crypto_aes_expand_key which was removed with the below commit:
>>>>
>>>> commit 5bb12d7825adf0e80b849a273834f3131a6cc4e1
>>>> Author: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
>>>> Date:   Tue Jul 2 21:41:33 2019 +0200
>>>>
>>>>     crypto: aes-generic - drop key expansion routine in favor of library
>>>> version
>>>>
>>>> The key that is being expanded is from the crypto aes(cbc) testsuite:
>>>>
>>>>   }, { /* From NIST SP800-38A */
>>>>                 .key    = "\x8e\x73\xb0\xf7\xda\x0e\x64\x52"
>>>>                           "\xc8\x10\xf3\x2b\x80\x90\x79\xe5"
>>>>                           "\x62\xf8\xea\xd2\x52\x2c\x6b\x7b",
>>>>                 .klen   = 24,
>>>>
>>>>
>>>> The older version crypto_aes_expand_key output that passes the cbc(aes)
>>>> decryption test:
> ...
>>>>
>>>> The difference is between 52nd index through 59.
>>>>
>>>> Any ideas if this is expected?
>>>>
>>>
>>> Yes, this is expected. This particular test vector uses a 192 bit key,
>>> so those values are DC/ignored.
>>
>> Thanks for the quick response. However with the new implementation
>> decryption test case fails for me with wrong result.
> 
> Can you share more details please? Platform, endianness, etc ..

Ard,

I am trying to get aes working on a yet to be upstream TI HW crypto
Accelerator SA2UL. It is little endian.

I had posted a series earlier this year:

https://lkml.org/lkml/2019/6/28/20

The device expects the inverse key for decryption.

In the earlier working version i was copying the ctx.key_enc[48] to
ctx.key_enc[53] index of the ctx.key_enc array as the 24 bytes of
decryption key to my hardware.

Now as told earlier the 52nd & 53rd words are changed and hence i end up
in wrong result.

Fail:

ctx.key_dec[48] = 0xf7b0738e & ctx.key_enc[48] = 0x6fa08be9
ctx.key_dec[49] = 0x52640eda & ctx.key_enc[49] = 0x3c778c44
ctx.key_dec[50] = 0x2bf310c8 & ctx.key_enc[50] = 0x472cc8e
ctx.key_dec[51] = 0xe5799080 & ctx.key_enc[51] = 0x2220001
ctx.key_dec[52] = 0x13eaf950 & ctx.key_enc[52] = 0x13eaf850
ctx.key_dec[53] = 0xffff8000 & ctx.key_enc[53] = 0xffff8000

Pass:

ctx.key_dec[48] = 0xf7b0738e & ctx.key_enc[48] = 0x6fa08be9
ctx.key_dec[49] = 0x52640eda & ctx.key_enc[49] = 0x3c778c44
ctx.key_dec[50] = 0x2bf310c8 & ctx.key_enc[50] = 0x472cc8e
ctx.key_dec[51] = 0xe5799080 & ctx.key_enc[51] = 0x2220001
ctx.key_dec[52] = 0x105127e8 & ctx.key_enc[52] = 0x68342d29
ctx.key_dec[53] = 0xffff8000 & ctx.key_enc[53] = 0xddd31195

- Keerthy
.
> 

Attachment: pEpkey.asc
Description: application/pgp-keys


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

  Powered by Linux