* aes_expandkey giving wrong expanded keys over crypto_aes_expand_key(older deprecated implementation under aes_generic)
@ 2019-12-10 9:35 Keerthy
2019-12-10 10:01 ` Ard Biesheuvel
0 siblings, 1 reply; 7+ messages in thread
From: Keerthy @ 2019-12-10 9:35 UTC (permalink / raw)
To: linux-crypto, ard.biesheuvel; +Cc: Kristo, Tero, Herbert Xu
[-- Attachment #1: Type: text/plain, Size: 8302 bytes --]
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@linaro.org>
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:
ctx.key_dec[0] = 0x6fa08be9 & ctx.key_enc[0] = 0xf7b0738e
ctx.key_dec[1] = 0x3c778c44 & ctx.key_enc[1] = 0x52640eda
ctx.key_dec[2] = 0x472cc8e & ctx.key_enc[2] = 0x2bf310c8
ctx.key_dec[3] = 0x2220001 & ctx.key_enc[3] = 0xe5799080
ctx.key_dec[4] = 0x441649ac & ctx.key_enc[4] = 0xd2eaf862
ctx.key_dec[5] = 0xb71057e5 & ctx.key_enc[5] = 0x7b6b2c52
ctx.key_dec[6] = 0x758ac046 & ctx.key_enc[6] = 0xf7910cfe
ctx.key_dec[7] = 0xad2c9bc8 & ctx.key_enc[7] = 0xa5f50224
ctx.key_dec[8] = 0xc29a97a3 & ctx.key_enc[8] = 0x8e0612ec
ctx.key_dec[9] = 0xd8a65b8e & ctx.key_enc[9] = 0x6b7f826c
ctx.key_dec[10] = 0xe6c92ce1 & ctx.key_enc[10] = 0xb9957a0e
ctx.key_dec[11] = 0xba72b254 & ctx.key_enc[11] = 0xc2fe565c
ctx.key_dec[12] = 0x5822b4f3 & ctx.key_enc[12] = 0xbdb4b74d
ctx.key_dec[13] = 0x5cbb9eb5 & ctx.key_enc[13] = 0x1841b569
ctx.key_dec[14] = 0xfe64fbf8 & ctx.key_enc[14] = 0x9647a785
ctx.key_dec[15] = 0xf3061e49 & ctx.key_enc[15] = 0xfd3825e9
ctx.key_dec[16] = 0xa2df654d & ctx.key_enc[16] = 0x44ad5fe7
ctx.key_dec[17] = 0xd62e5b1 & ctx.key_enc[17] = 0x865309bb
ctx.key_dec[18] = 0x319c89ea & ctx.key_enc[18] = 0x57f05a48
ctx.key_dec[19] = 0x1a3ccc2d & ctx.key_enc[19] = 0x4fb1ef21
ctx.key_dec[20] = 0x3cfe6c5b & ctx.key_enc[20] = 0xd9f648a4
ctx.key_dec[21] = 0x2ba045c7 & ctx.key_enc[21] = 0x24ce6d4d
ctx.key_dec[22] = 0x72a5b9f8 & ctx.key_enc[22] = 0x606332aa
ctx.key_dec[23] = 0x4992a46 & ctx.key_enc[23] = 0xe6303b11
ctx.key_dec[24] = 0xf8b7ddc5 & ctx.key_enc[24] = 0xd57e5ea2
ctx.key_dec[25] = 0x763c93be & ctx.key_enc[25] = 0x9acfb183
ctx.key_dec[26] = 0xa6464f0b & ctx.key_enc[26] = 0x4339f927
ctx.key_dec[27] = 0xafbd80fc & ctx.key_enc[27] = 0x67f7946a
ctx.key_dec[28] = 0xd07adcb5 & ctx.key_enc[28] = 0x794a6c0
ctx.key_dec[29] = 0x9fbcff7 & ctx.key_enc[29] = 0xe1a49dd1
ctx.key_dec[30] = 0x9343eca7 & ctx.key_enc[30] = 0xeb8617ec
ctx.key_dec[31] = 0x175e299c & ctx.key_enc[31] = 0x7149a66f
ctx.key_dec[32] = 0x9ab82350 & ctx.key_enc[32] = 0x32705f48
ctx.key_dec[33] = 0x841dc53b & ctx.key_enc[33] = 0x5587cb22
ctx.key_dec[34] = 0x37194bd0 & ctx.key_enc[34] = 0x52136de2
ctx.key_dec[35] = 0x8e8b4e7b & ctx.key_enc[35] = 0xb3b7f033
ctx.key_dec[36] = 0x4445b341 & ctx.key_enc[36] = 0x28ebbe40
ctx.key_dec[37] = 0xb99205ab & ctx.key_enc[37] = 0x59a2182f
ctx.key_dec[38] = 0x5ef192ce & ctx.key_enc[38] = 0x6bd24767
ctx.key_dec[39] = 0xd9811342 & ctx.key_enc[39] = 0x3e558c45
ctx.key_dec[40] = 0xe7639765 & ctx.key_enc[40] = 0x6c46e1a7
ctx.key_dec[41] = 0x8770818c & ctx.key_enc[41] = 0xdff11194
ctx.key_dec[42] = 0x43393012 & ctx.key_enc[42] = 0xa751f82
ctx.key_dec[43] = 0x1ea5e66b & ctx.key_enc[43] = 0x53d707ad
ctx.key_dec[44] = 0xc449b19e & ctx.key_enc[44] = 0x380540ca
ctx.key_dec[45] = 0x5d9cd679 & ctx.key_enc[45] = 0x650cc8f
ctx.key_dec[46] = 0x7ca2b4fe & ctx.key_enc[46] = 0x6a162d28
ctx.key_dec[47] = 0xfdd7b6ea & ctx.key_enc[47] = 0xb5e73cbc
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
ctx.key_dec[54] = 0xffffffd0 & ctx.key_enc[54] = 0x109bb3b8
ctx.key_dec[55] = 0x0 & ctx.key_enc[55] = 0xffff8000
ctx.key_dec[56] = 0x11053870 & ctx.key_enc[56] = 0x13caf9f5
ctx.key_dec[57] = 0xffff8000 & ctx.key_enc[57] = 0xffff8000
ctx.key_dec[58] = 0x5f5e0ff & ctx.key_enc[58] = 0x93caf9e7
ctx.key_dec[59] = 0x0 & ctx.key_enc[59] = 0xffff8000
Newer aes_expandkey is failing the decryption test and the expansion:
ctx.key_dec[0] = 0x6fa08be9 & ctx.key_enc[0] = 0xf7b0738e
ctx.key_dec[1] = 0x3c778c44 & ctx.key_enc[1] = 0x52640eda
ctx.key_dec[2] = 0x472cc8e & ctx.key_enc[2] = 0x2bf310c8
ctx.key_dec[3] = 0x2220001 & ctx.key_enc[3] = 0xe5799080
ctx.key_dec[4] = 0x441649ac & ctx.key_enc[4] = 0xd2eaf862
ctx.key_dec[5] = 0xb71057e5 & ctx.key_enc[5] = 0x7b6b2c52
ctx.key_dec[6] = 0x758ac046 & ctx.key_enc[6] = 0xf7910cfe
ctx.key_dec[7] = 0xad2c9bc8 & ctx.key_enc[7] = 0xa5f50224
ctx.key_dec[8] = 0xc29a97a3 & ctx.key_enc[8] = 0x8e0612ec
ctx.key_dec[9] = 0xd8a65b8e & ctx.key_enc[9] = 0x6b7f826c
ctx.key_dec[10] = 0xe6c92ce1 & ctx.key_enc[10] = 0xb9957a0e
ctx.key_dec[11] = 0xba72b254 & ctx.key_enc[11] = 0xc2fe565c
ctx.key_dec[12] = 0x5822b4f3 & ctx.key_enc[12] = 0xbdb4b74d
ctx.key_dec[13] = 0x5cbb9eb5 & ctx.key_enc[13] = 0x1841b569
ctx.key_dec[14] = 0xfe64fbf8 & ctx.key_enc[14] = 0x9647a785
ctx.key_dec[15] = 0xf3061e49 & ctx.key_enc[15] = 0xfd3825e9
ctx.key_dec[16] = 0xa2df654d & ctx.key_enc[16] = 0x44ad5fe7
ctx.key_dec[17] = 0xd62e5b1 & ctx.key_enc[17] = 0x865309bb
ctx.key_dec[18] = 0x319c89ea & ctx.key_enc[18] = 0x57f05a48
ctx.key_dec[19] = 0x1a3ccc2d & ctx.key_enc[19] = 0x4fb1ef21
ctx.key_dec[20] = 0x3cfe6c5b & ctx.key_enc[20] = 0xd9f648a4
ctx.key_dec[21] = 0x2ba045c7 & ctx.key_enc[21] = 0x24ce6d4d
ctx.key_dec[22] = 0x72a5b9f8 & ctx.key_enc[22] = 0x606332aa
ctx.key_dec[23] = 0x4992a46 & ctx.key_enc[23] = 0xe6303b11
ctx.key_dec[24] = 0xf8b7ddc5 & ctx.key_enc[24] = 0xd57e5ea2
ctx.key_dec[25] = 0x763c93be & ctx.key_enc[25] = 0x9acfb183
ctx.key_dec[26] = 0xa6464f0b & ctx.key_enc[26] = 0x4339f927
ctx.key_dec[27] = 0xafbd80fc & ctx.key_enc[27] = 0x67f7946a
ctx.key_dec[28] = 0xd07adcb5 & ctx.key_enc[28] = 0x794a6c0
ctx.key_dec[29] = 0x9fbcff7 & ctx.key_enc[29] = 0xe1a49dd1
ctx.key_dec[30] = 0x9343eca7 & ctx.key_enc[30] = 0xeb8617ec
ctx.key_dec[31] = 0x175e299c & ctx.key_enc[31] = 0x7149a66f
ctx.key_dec[32] = 0x9ab82350 & ctx.key_enc[32] = 0x32705f48
ctx.key_dec[33] = 0x841dc53b & ctx.key_enc[33] = 0x5587cb22
ctx.key_dec[34] = 0x37194bd0 & ctx.key_enc[34] = 0x52136de2
ctx.key_dec[35] = 0x8e8b4e7b & ctx.key_enc[35] = 0xb3b7f033
ctx.key_dec[36] = 0x4445b341 & ctx.key_enc[36] = 0x28ebbe40
ctx.key_dec[37] = 0xb99205ab & ctx.key_enc[37] = 0x59a2182f
ctx.key_dec[38] = 0x5ef192ce & ctx.key_enc[38] = 0x6bd24767
ctx.key_dec[39] = 0xd9811342 & ctx.key_enc[39] = 0x3e558c45
ctx.key_dec[40] = 0xe7639765 & ctx.key_enc[40] = 0x6c46e1a7
ctx.key_dec[41] = 0x8770818c & ctx.key_enc[41] = 0xdff11194
ctx.key_dec[42] = 0x43393012 & ctx.key_enc[42] = 0xa751f82
ctx.key_dec[43] = 0x1ea5e66b & ctx.key_enc[43] = 0x53d707ad
ctx.key_dec[44] = 0xc449b19e & ctx.key_enc[44] = 0x380540ca
ctx.key_dec[45] = 0x5d9cd679 & ctx.key_enc[45] = 0x650cc8f
ctx.key_dec[46] = 0x7ca2b4fe & ctx.key_enc[46] = 0x6a162d28
ctx.key_dec[47] = 0xfdd7b6ea & ctx.key_enc[47] = 0xb5e73cbc
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
ctx.key_dec[54] = 0x105146b0 & ctx.key_enc[54] = 0x109ba1f8
ctx.key_dec[55] = 0xffff8000 & ctx.key_enc[55] = 0xffff8000
ctx.key_dec[56] = 0x13eaf950 & ctx.key_enc[56] = 0x13eaf9f5
ctx.key_dec[57] = 0xffff8000 & ctx.key_enc[57] = 0xffff8000
ctx.key_dec[58] = 0x105146c0 & ctx.key_enc[58] = 0x93eaf9e7
ctx.key_dec[59] = 0xffff8000 & ctx.key_enc[59] = 0xffff8000
The difference is between 52nd index through 59.
Any ideas if this is expected?
Best Regards,
Keerthy
[-- Attachment #2: pEpkey.asc --]
[-- Type: application/pgp-keys, Size: 9065 bytes --]
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: aes_expandkey giving wrong expanded keys over crypto_aes_expand_key(older deprecated implementation under aes_generic)
2019-12-10 9:35 aes_expandkey giving wrong expanded keys over crypto_aes_expand_key(older deprecated implementation under aes_generic) Keerthy
@ 2019-12-10 10:01 ` Ard Biesheuvel
2019-12-10 10:06 ` Keerthy
0 siblings, 1 reply; 7+ messages in thread
From: Ard Biesheuvel @ 2019-12-10 10:01 UTC (permalink / raw)
To: Keerthy
Cc: open list:HARDWARE RANDOM NUMBER GENERATOR CORE, Kristo, Tero,
Herbert Xu
Hello Keerthy,
On Tue, 10 Dec 2019 at 10:35, Keerthy <j-keerthy@ti.com> 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@linaro.org>
> 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:
>
> ctx.key_dec[0] = 0x6fa08be9 & ctx.key_enc[0] = 0xf7b0738e
> ctx.key_dec[1] = 0x3c778c44 & ctx.key_enc[1] = 0x52640eda
> ctx.key_dec[2] = 0x472cc8e & ctx.key_enc[2] = 0x2bf310c8
> ctx.key_dec[3] = 0x2220001 & ctx.key_enc[3] = 0xe5799080
> ctx.key_dec[4] = 0x441649ac & ctx.key_enc[4] = 0xd2eaf862
> ctx.key_dec[5] = 0xb71057e5 & ctx.key_enc[5] = 0x7b6b2c52
> ctx.key_dec[6] = 0x758ac046 & ctx.key_enc[6] = 0xf7910cfe
> ctx.key_dec[7] = 0xad2c9bc8 & ctx.key_enc[7] = 0xa5f50224
> ctx.key_dec[8] = 0xc29a97a3 & ctx.key_enc[8] = 0x8e0612ec
> ctx.key_dec[9] = 0xd8a65b8e & ctx.key_enc[9] = 0x6b7f826c
> ctx.key_dec[10] = 0xe6c92ce1 & ctx.key_enc[10] = 0xb9957a0e
> ctx.key_dec[11] = 0xba72b254 & ctx.key_enc[11] = 0xc2fe565c
> ctx.key_dec[12] = 0x5822b4f3 & ctx.key_enc[12] = 0xbdb4b74d
> ctx.key_dec[13] = 0x5cbb9eb5 & ctx.key_enc[13] = 0x1841b569
> ctx.key_dec[14] = 0xfe64fbf8 & ctx.key_enc[14] = 0x9647a785
> ctx.key_dec[15] = 0xf3061e49 & ctx.key_enc[15] = 0xfd3825e9
> ctx.key_dec[16] = 0xa2df654d & ctx.key_enc[16] = 0x44ad5fe7
> ctx.key_dec[17] = 0xd62e5b1 & ctx.key_enc[17] = 0x865309bb
> ctx.key_dec[18] = 0x319c89ea & ctx.key_enc[18] = 0x57f05a48
> ctx.key_dec[19] = 0x1a3ccc2d & ctx.key_enc[19] = 0x4fb1ef21
> ctx.key_dec[20] = 0x3cfe6c5b & ctx.key_enc[20] = 0xd9f648a4
> ctx.key_dec[21] = 0x2ba045c7 & ctx.key_enc[21] = 0x24ce6d4d
> ctx.key_dec[22] = 0x72a5b9f8 & ctx.key_enc[22] = 0x606332aa
> ctx.key_dec[23] = 0x4992a46 & ctx.key_enc[23] = 0xe6303b11
> ctx.key_dec[24] = 0xf8b7ddc5 & ctx.key_enc[24] = 0xd57e5ea2
> ctx.key_dec[25] = 0x763c93be & ctx.key_enc[25] = 0x9acfb183
> ctx.key_dec[26] = 0xa6464f0b & ctx.key_enc[26] = 0x4339f927
> ctx.key_dec[27] = 0xafbd80fc & ctx.key_enc[27] = 0x67f7946a
> ctx.key_dec[28] = 0xd07adcb5 & ctx.key_enc[28] = 0x794a6c0
> ctx.key_dec[29] = 0x9fbcff7 & ctx.key_enc[29] = 0xe1a49dd1
> ctx.key_dec[30] = 0x9343eca7 & ctx.key_enc[30] = 0xeb8617ec
> ctx.key_dec[31] = 0x175e299c & ctx.key_enc[31] = 0x7149a66f
> ctx.key_dec[32] = 0x9ab82350 & ctx.key_enc[32] = 0x32705f48
> ctx.key_dec[33] = 0x841dc53b & ctx.key_enc[33] = 0x5587cb22
> ctx.key_dec[34] = 0x37194bd0 & ctx.key_enc[34] = 0x52136de2
> ctx.key_dec[35] = 0x8e8b4e7b & ctx.key_enc[35] = 0xb3b7f033
> ctx.key_dec[36] = 0x4445b341 & ctx.key_enc[36] = 0x28ebbe40
> ctx.key_dec[37] = 0xb99205ab & ctx.key_enc[37] = 0x59a2182f
> ctx.key_dec[38] = 0x5ef192ce & ctx.key_enc[38] = 0x6bd24767
> ctx.key_dec[39] = 0xd9811342 & ctx.key_enc[39] = 0x3e558c45
> ctx.key_dec[40] = 0xe7639765 & ctx.key_enc[40] = 0x6c46e1a7
> ctx.key_dec[41] = 0x8770818c & ctx.key_enc[41] = 0xdff11194
> ctx.key_dec[42] = 0x43393012 & ctx.key_enc[42] = 0xa751f82
> ctx.key_dec[43] = 0x1ea5e66b & ctx.key_enc[43] = 0x53d707ad
> ctx.key_dec[44] = 0xc449b19e & ctx.key_enc[44] = 0x380540ca
> ctx.key_dec[45] = 0x5d9cd679 & ctx.key_enc[45] = 0x650cc8f
> ctx.key_dec[46] = 0x7ca2b4fe & ctx.key_enc[46] = 0x6a162d28
> ctx.key_dec[47] = 0xfdd7b6ea & ctx.key_enc[47] = 0xb5e73cbc
> 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
> ctx.key_dec[54] = 0xffffffd0 & ctx.key_enc[54] = 0x109bb3b8
> ctx.key_dec[55] = 0x0 & ctx.key_enc[55] = 0xffff8000
> ctx.key_dec[56] = 0x11053870 & ctx.key_enc[56] = 0x13caf9f5
> ctx.key_dec[57] = 0xffff8000 & ctx.key_enc[57] = 0xffff8000
> ctx.key_dec[58] = 0x5f5e0ff & ctx.key_enc[58] = 0x93caf9e7
> ctx.key_dec[59] = 0x0 & ctx.key_enc[59] = 0xffff8000
>
> Newer aes_expandkey is failing the decryption test and the expansion:
>
> ctx.key_dec[0] = 0x6fa08be9 & ctx.key_enc[0] = 0xf7b0738e
> ctx.key_dec[1] = 0x3c778c44 & ctx.key_enc[1] = 0x52640eda
> ctx.key_dec[2] = 0x472cc8e & ctx.key_enc[2] = 0x2bf310c8
> ctx.key_dec[3] = 0x2220001 & ctx.key_enc[3] = 0xe5799080
> ctx.key_dec[4] = 0x441649ac & ctx.key_enc[4] = 0xd2eaf862
> ctx.key_dec[5] = 0xb71057e5 & ctx.key_enc[5] = 0x7b6b2c52
> ctx.key_dec[6] = 0x758ac046 & ctx.key_enc[6] = 0xf7910cfe
> ctx.key_dec[7] = 0xad2c9bc8 & ctx.key_enc[7] = 0xa5f50224
> ctx.key_dec[8] = 0xc29a97a3 & ctx.key_enc[8] = 0x8e0612ec
> ctx.key_dec[9] = 0xd8a65b8e & ctx.key_enc[9] = 0x6b7f826c
> ctx.key_dec[10] = 0xe6c92ce1 & ctx.key_enc[10] = 0xb9957a0e
> ctx.key_dec[11] = 0xba72b254 & ctx.key_enc[11] = 0xc2fe565c
> ctx.key_dec[12] = 0x5822b4f3 & ctx.key_enc[12] = 0xbdb4b74d
> ctx.key_dec[13] = 0x5cbb9eb5 & ctx.key_enc[13] = 0x1841b569
> ctx.key_dec[14] = 0xfe64fbf8 & ctx.key_enc[14] = 0x9647a785
> ctx.key_dec[15] = 0xf3061e49 & ctx.key_enc[15] = 0xfd3825e9
> ctx.key_dec[16] = 0xa2df654d & ctx.key_enc[16] = 0x44ad5fe7
> ctx.key_dec[17] = 0xd62e5b1 & ctx.key_enc[17] = 0x865309bb
> ctx.key_dec[18] = 0x319c89ea & ctx.key_enc[18] = 0x57f05a48
> ctx.key_dec[19] = 0x1a3ccc2d & ctx.key_enc[19] = 0x4fb1ef21
> ctx.key_dec[20] = 0x3cfe6c5b & ctx.key_enc[20] = 0xd9f648a4
> ctx.key_dec[21] = 0x2ba045c7 & ctx.key_enc[21] = 0x24ce6d4d
> ctx.key_dec[22] = 0x72a5b9f8 & ctx.key_enc[22] = 0x606332aa
> ctx.key_dec[23] = 0x4992a46 & ctx.key_enc[23] = 0xe6303b11
> ctx.key_dec[24] = 0xf8b7ddc5 & ctx.key_enc[24] = 0xd57e5ea2
> ctx.key_dec[25] = 0x763c93be & ctx.key_enc[25] = 0x9acfb183
> ctx.key_dec[26] = 0xa6464f0b & ctx.key_enc[26] = 0x4339f927
> ctx.key_dec[27] = 0xafbd80fc & ctx.key_enc[27] = 0x67f7946a
> ctx.key_dec[28] = 0xd07adcb5 & ctx.key_enc[28] = 0x794a6c0
> ctx.key_dec[29] = 0x9fbcff7 & ctx.key_enc[29] = 0xe1a49dd1
> ctx.key_dec[30] = 0x9343eca7 & ctx.key_enc[30] = 0xeb8617ec
> ctx.key_dec[31] = 0x175e299c & ctx.key_enc[31] = 0x7149a66f
> ctx.key_dec[32] = 0x9ab82350 & ctx.key_enc[32] = 0x32705f48
> ctx.key_dec[33] = 0x841dc53b & ctx.key_enc[33] = 0x5587cb22
> ctx.key_dec[34] = 0x37194bd0 & ctx.key_enc[34] = 0x52136de2
> ctx.key_dec[35] = 0x8e8b4e7b & ctx.key_enc[35] = 0xb3b7f033
> ctx.key_dec[36] = 0x4445b341 & ctx.key_enc[36] = 0x28ebbe40
> ctx.key_dec[37] = 0xb99205ab & ctx.key_enc[37] = 0x59a2182f
> ctx.key_dec[38] = 0x5ef192ce & ctx.key_enc[38] = 0x6bd24767
> ctx.key_dec[39] = 0xd9811342 & ctx.key_enc[39] = 0x3e558c45
> ctx.key_dec[40] = 0xe7639765 & ctx.key_enc[40] = 0x6c46e1a7
> ctx.key_dec[41] = 0x8770818c & ctx.key_enc[41] = 0xdff11194
> ctx.key_dec[42] = 0x43393012 & ctx.key_enc[42] = 0xa751f82
> ctx.key_dec[43] = 0x1ea5e66b & ctx.key_enc[43] = 0x53d707ad
> ctx.key_dec[44] = 0xc449b19e & ctx.key_enc[44] = 0x380540ca
> ctx.key_dec[45] = 0x5d9cd679 & ctx.key_enc[45] = 0x650cc8f
> ctx.key_dec[46] = 0x7ca2b4fe & ctx.key_enc[46] = 0x6a162d28
> ctx.key_dec[47] = 0xfdd7b6ea & ctx.key_enc[47] = 0xb5e73cbc
> 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
> ctx.key_dec[54] = 0x105146b0 & ctx.key_enc[54] = 0x109ba1f8
> ctx.key_dec[55] = 0xffff8000 & ctx.key_enc[55] = 0xffff8000
> ctx.key_dec[56] = 0x13eaf950 & ctx.key_enc[56] = 0x13eaf9f5
> ctx.key_dec[57] = 0xffff8000 & ctx.key_enc[57] = 0xffff8000
> ctx.key_dec[58] = 0x105146c0 & ctx.key_enc[58] = 0x93eaf9e7
> ctx.key_dec[59] = 0xffff8000 & ctx.key_enc[59] = 0xffff8000
>
> 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.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: aes_expandkey giving wrong expanded keys over crypto_aes_expand_key(older deprecated implementation under aes_generic)
2019-12-10 10:01 ` Ard Biesheuvel
@ 2019-12-10 10:06 ` Keerthy
2019-12-10 10:07 ` Ard Biesheuvel
0 siblings, 1 reply; 7+ messages in thread
From: Keerthy @ 2019-12-10 10:06 UTC (permalink / raw)
To: Ard Biesheuvel
Cc: open list:HARDWARE RANDOM NUMBER GENERATOR CORE, Kristo, Tero,
Herbert Xu
[-- Attachment #1: Type: text/plain, Size: 9108 bytes --]
On 10/12/19 3:31 pm, Ard Biesheuvel wrote:
> Hello Keerthy,
>
> On Tue, 10 Dec 2019 at 10:35, Keerthy <j-keerthy@ti.com> 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@linaro.org>
>> 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:
>>
>> ctx.key_dec[0] = 0x6fa08be9 & ctx.key_enc[0] = 0xf7b0738e
>> ctx.key_dec[1] = 0x3c778c44 & ctx.key_enc[1] = 0x52640eda
>> ctx.key_dec[2] = 0x472cc8e & ctx.key_enc[2] = 0x2bf310c8
>> ctx.key_dec[3] = 0x2220001 & ctx.key_enc[3] = 0xe5799080
>> ctx.key_dec[4] = 0x441649ac & ctx.key_enc[4] = 0xd2eaf862
>> ctx.key_dec[5] = 0xb71057e5 & ctx.key_enc[5] = 0x7b6b2c52
>> ctx.key_dec[6] = 0x758ac046 & ctx.key_enc[6] = 0xf7910cfe
>> ctx.key_dec[7] = 0xad2c9bc8 & ctx.key_enc[7] = 0xa5f50224
>> ctx.key_dec[8] = 0xc29a97a3 & ctx.key_enc[8] = 0x8e0612ec
>> ctx.key_dec[9] = 0xd8a65b8e & ctx.key_enc[9] = 0x6b7f826c
>> ctx.key_dec[10] = 0xe6c92ce1 & ctx.key_enc[10] = 0xb9957a0e
>> ctx.key_dec[11] = 0xba72b254 & ctx.key_enc[11] = 0xc2fe565c
>> ctx.key_dec[12] = 0x5822b4f3 & ctx.key_enc[12] = 0xbdb4b74d
>> ctx.key_dec[13] = 0x5cbb9eb5 & ctx.key_enc[13] = 0x1841b569
>> ctx.key_dec[14] = 0xfe64fbf8 & ctx.key_enc[14] = 0x9647a785
>> ctx.key_dec[15] = 0xf3061e49 & ctx.key_enc[15] = 0xfd3825e9
>> ctx.key_dec[16] = 0xa2df654d & ctx.key_enc[16] = 0x44ad5fe7
>> ctx.key_dec[17] = 0xd62e5b1 & ctx.key_enc[17] = 0x865309bb
>> ctx.key_dec[18] = 0x319c89ea & ctx.key_enc[18] = 0x57f05a48
>> ctx.key_dec[19] = 0x1a3ccc2d & ctx.key_enc[19] = 0x4fb1ef21
>> ctx.key_dec[20] = 0x3cfe6c5b & ctx.key_enc[20] = 0xd9f648a4
>> ctx.key_dec[21] = 0x2ba045c7 & ctx.key_enc[21] = 0x24ce6d4d
>> ctx.key_dec[22] = 0x72a5b9f8 & ctx.key_enc[22] = 0x606332aa
>> ctx.key_dec[23] = 0x4992a46 & ctx.key_enc[23] = 0xe6303b11
>> ctx.key_dec[24] = 0xf8b7ddc5 & ctx.key_enc[24] = 0xd57e5ea2
>> ctx.key_dec[25] = 0x763c93be & ctx.key_enc[25] = 0x9acfb183
>> ctx.key_dec[26] = 0xa6464f0b & ctx.key_enc[26] = 0x4339f927
>> ctx.key_dec[27] = 0xafbd80fc & ctx.key_enc[27] = 0x67f7946a
>> ctx.key_dec[28] = 0xd07adcb5 & ctx.key_enc[28] = 0x794a6c0
>> ctx.key_dec[29] = 0x9fbcff7 & ctx.key_enc[29] = 0xe1a49dd1
>> ctx.key_dec[30] = 0x9343eca7 & ctx.key_enc[30] = 0xeb8617ec
>> ctx.key_dec[31] = 0x175e299c & ctx.key_enc[31] = 0x7149a66f
>> ctx.key_dec[32] = 0x9ab82350 & ctx.key_enc[32] = 0x32705f48
>> ctx.key_dec[33] = 0x841dc53b & ctx.key_enc[33] = 0x5587cb22
>> ctx.key_dec[34] = 0x37194bd0 & ctx.key_enc[34] = 0x52136de2
>> ctx.key_dec[35] = 0x8e8b4e7b & ctx.key_enc[35] = 0xb3b7f033
>> ctx.key_dec[36] = 0x4445b341 & ctx.key_enc[36] = 0x28ebbe40
>> ctx.key_dec[37] = 0xb99205ab & ctx.key_enc[37] = 0x59a2182f
>> ctx.key_dec[38] = 0x5ef192ce & ctx.key_enc[38] = 0x6bd24767
>> ctx.key_dec[39] = 0xd9811342 & ctx.key_enc[39] = 0x3e558c45
>> ctx.key_dec[40] = 0xe7639765 & ctx.key_enc[40] = 0x6c46e1a7
>> ctx.key_dec[41] = 0x8770818c & ctx.key_enc[41] = 0xdff11194
>> ctx.key_dec[42] = 0x43393012 & ctx.key_enc[42] = 0xa751f82
>> ctx.key_dec[43] = 0x1ea5e66b & ctx.key_enc[43] = 0x53d707ad
>> ctx.key_dec[44] = 0xc449b19e & ctx.key_enc[44] = 0x380540ca
>> ctx.key_dec[45] = 0x5d9cd679 & ctx.key_enc[45] = 0x650cc8f
>> ctx.key_dec[46] = 0x7ca2b4fe & ctx.key_enc[46] = 0x6a162d28
>> ctx.key_dec[47] = 0xfdd7b6ea & ctx.key_enc[47] = 0xb5e73cbc
>> 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
>> ctx.key_dec[54] = 0xffffffd0 & ctx.key_enc[54] = 0x109bb3b8
>> ctx.key_dec[55] = 0x0 & ctx.key_enc[55] = 0xffff8000
>> ctx.key_dec[56] = 0x11053870 & ctx.key_enc[56] = 0x13caf9f5
>> ctx.key_dec[57] = 0xffff8000 & ctx.key_enc[57] = 0xffff8000
>> ctx.key_dec[58] = 0x5f5e0ff & ctx.key_enc[58] = 0x93caf9e7
>> ctx.key_dec[59] = 0x0 & ctx.key_enc[59] = 0xffff8000
>>
>> Newer aes_expandkey is failing the decryption test and the expansion:
>>
>> ctx.key_dec[0] = 0x6fa08be9 & ctx.key_enc[0] = 0xf7b0738e
>> ctx.key_dec[1] = 0x3c778c44 & ctx.key_enc[1] = 0x52640eda
>> ctx.key_dec[2] = 0x472cc8e & ctx.key_enc[2] = 0x2bf310c8
>> ctx.key_dec[3] = 0x2220001 & ctx.key_enc[3] = 0xe5799080
>> ctx.key_dec[4] = 0x441649ac & ctx.key_enc[4] = 0xd2eaf862
>> ctx.key_dec[5] = 0xb71057e5 & ctx.key_enc[5] = 0x7b6b2c52
>> ctx.key_dec[6] = 0x758ac046 & ctx.key_enc[6] = 0xf7910cfe
>> ctx.key_dec[7] = 0xad2c9bc8 & ctx.key_enc[7] = 0xa5f50224
>> ctx.key_dec[8] = 0xc29a97a3 & ctx.key_enc[8] = 0x8e0612ec
>> ctx.key_dec[9] = 0xd8a65b8e & ctx.key_enc[9] = 0x6b7f826c
>> ctx.key_dec[10] = 0xe6c92ce1 & ctx.key_enc[10] = 0xb9957a0e
>> ctx.key_dec[11] = 0xba72b254 & ctx.key_enc[11] = 0xc2fe565c
>> ctx.key_dec[12] = 0x5822b4f3 & ctx.key_enc[12] = 0xbdb4b74d
>> ctx.key_dec[13] = 0x5cbb9eb5 & ctx.key_enc[13] = 0x1841b569
>> ctx.key_dec[14] = 0xfe64fbf8 & ctx.key_enc[14] = 0x9647a785
>> ctx.key_dec[15] = 0xf3061e49 & ctx.key_enc[15] = 0xfd3825e9
>> ctx.key_dec[16] = 0xa2df654d & ctx.key_enc[16] = 0x44ad5fe7
>> ctx.key_dec[17] = 0xd62e5b1 & ctx.key_enc[17] = 0x865309bb
>> ctx.key_dec[18] = 0x319c89ea & ctx.key_enc[18] = 0x57f05a48
>> ctx.key_dec[19] = 0x1a3ccc2d & ctx.key_enc[19] = 0x4fb1ef21
>> ctx.key_dec[20] = 0x3cfe6c5b & ctx.key_enc[20] = 0xd9f648a4
>> ctx.key_dec[21] = 0x2ba045c7 & ctx.key_enc[21] = 0x24ce6d4d
>> ctx.key_dec[22] = 0x72a5b9f8 & ctx.key_enc[22] = 0x606332aa
>> ctx.key_dec[23] = 0x4992a46 & ctx.key_enc[23] = 0xe6303b11
>> ctx.key_dec[24] = 0xf8b7ddc5 & ctx.key_enc[24] = 0xd57e5ea2
>> ctx.key_dec[25] = 0x763c93be & ctx.key_enc[25] = 0x9acfb183
>> ctx.key_dec[26] = 0xa6464f0b & ctx.key_enc[26] = 0x4339f927
>> ctx.key_dec[27] = 0xafbd80fc & ctx.key_enc[27] = 0x67f7946a
>> ctx.key_dec[28] = 0xd07adcb5 & ctx.key_enc[28] = 0x794a6c0
>> ctx.key_dec[29] = 0x9fbcff7 & ctx.key_enc[29] = 0xe1a49dd1
>> ctx.key_dec[30] = 0x9343eca7 & ctx.key_enc[30] = 0xeb8617ec
>> ctx.key_dec[31] = 0x175e299c & ctx.key_enc[31] = 0x7149a66f
>> ctx.key_dec[32] = 0x9ab82350 & ctx.key_enc[32] = 0x32705f48
>> ctx.key_dec[33] = 0x841dc53b & ctx.key_enc[33] = 0x5587cb22
>> ctx.key_dec[34] = 0x37194bd0 & ctx.key_enc[34] = 0x52136de2
>> ctx.key_dec[35] = 0x8e8b4e7b & ctx.key_enc[35] = 0xb3b7f033
>> ctx.key_dec[36] = 0x4445b341 & ctx.key_enc[36] = 0x28ebbe40
>> ctx.key_dec[37] = 0xb99205ab & ctx.key_enc[37] = 0x59a2182f
>> ctx.key_dec[38] = 0x5ef192ce & ctx.key_enc[38] = 0x6bd24767
>> ctx.key_dec[39] = 0xd9811342 & ctx.key_enc[39] = 0x3e558c45
>> ctx.key_dec[40] = 0xe7639765 & ctx.key_enc[40] = 0x6c46e1a7
>> ctx.key_dec[41] = 0x8770818c & ctx.key_enc[41] = 0xdff11194
>> ctx.key_dec[42] = 0x43393012 & ctx.key_enc[42] = 0xa751f82
>> ctx.key_dec[43] = 0x1ea5e66b & ctx.key_enc[43] = 0x53d707ad
>> ctx.key_dec[44] = 0xc449b19e & ctx.key_enc[44] = 0x380540ca
>> ctx.key_dec[45] = 0x5d9cd679 & ctx.key_enc[45] = 0x650cc8f
>> ctx.key_dec[46] = 0x7ca2b4fe & ctx.key_enc[46] = 0x6a162d28
>> ctx.key_dec[47] = 0xfdd7b6ea & ctx.key_enc[47] = 0xb5e73cbc
>> 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
>> ctx.key_dec[54] = 0x105146b0 & ctx.key_enc[54] = 0x109ba1f8
>> ctx.key_dec[55] = 0xffff8000 & ctx.key_enc[55] = 0xffff8000
>> ctx.key_dec[56] = 0x13eaf950 & ctx.key_enc[56] = 0x13eaf9f5
>> ctx.key_dec[57] = 0xffff8000 & ctx.key_enc[57] = 0xffff8000
>> ctx.key_dec[58] = 0x105146c0 & ctx.key_enc[58] = 0x93eaf9e7
>> ctx.key_dec[59] = 0xffff8000 & ctx.key_enc[59] = 0xffff8000
>>
>> 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.
>
[-- Attachment #2: pEpkey.asc --]
[-- Type: application/pgp-keys, Size: 9065 bytes --]
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: aes_expandkey giving wrong expanded keys over crypto_aes_expand_key(older deprecated implementation under aes_generic)
2019-12-10 10:06 ` Keerthy
@ 2019-12-10 10:07 ` Ard Biesheuvel
2019-12-10 11:04 ` Keerthy
0 siblings, 1 reply; 7+ messages in thread
From: Ard Biesheuvel @ 2019-12-10 10:07 UTC (permalink / raw)
To: Keerthy
Cc: open list:HARDWARE RANDOM NUMBER GENERATOR CORE, Kristo, Tero,
Herbert Xu
On Tue, 10 Dec 2019 at 11:06, Keerthy <j-keerthy@ti.com> wrote:
>
>
>
> On 10/12/19 3:31 pm, Ard Biesheuvel wrote:
> > Hello Keerthy,
> >
> > On Tue, 10 Dec 2019 at 10:35, Keerthy <j-keerthy@ti.com> 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@linaro.org>
> >> 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 ...
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: aes_expandkey giving wrong expanded keys over crypto_aes_expand_key(older deprecated implementation under aes_generic)
2019-12-10 10:07 ` Ard Biesheuvel
@ 2019-12-10 11:04 ` Keerthy
2019-12-10 13:53 ` Ard Biesheuvel
0 siblings, 1 reply; 7+ messages in thread
From: Keerthy @ 2019-12-10 11:04 UTC (permalink / raw)
To: Ard Biesheuvel
Cc: open list:HARDWARE RANDOM NUMBER GENERATOR CORE, Kristo, Tero,
Herbert Xu
[-- Attachment #1: Type: text/plain, Size: 2983 bytes --]
On 10/12/19 3:37 pm, Ard Biesheuvel wrote:
> On Tue, 10 Dec 2019 at 11:06, Keerthy <j-keerthy@ti.com> wrote:
>>
>>
>>
>> On 10/12/19 3:31 pm, Ard Biesheuvel wrote:
>>> Hello Keerthy,
>>>
>>> On Tue, 10 Dec 2019 at 10:35, Keerthy <j-keerthy@ti.com> 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@linaro.org>
>>>> 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 #2: pEpkey.asc --]
[-- Type: application/pgp-keys, Size: 9065 bytes --]
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: aes_expandkey giving wrong expanded keys over crypto_aes_expand_key(older deprecated implementation under aes_generic)
2019-12-10 11:04 ` Keerthy
@ 2019-12-10 13:53 ` Ard Biesheuvel
2019-12-11 6:22 ` Keerthy
0 siblings, 1 reply; 7+ messages in thread
From: Ard Biesheuvel @ 2019-12-10 13:53 UTC (permalink / raw)
To: Keerthy
Cc: open list:HARDWARE RANDOM NUMBER GENERATOR CORE, Kristo, Tero,
Herbert Xu
On Tue, 10 Dec 2019 at 12:04, Keerthy <j-keerthy@ti.com> wrote:
>
>
>
> On 10/12/19 3:37 pm, Ard Biesheuvel wrote:
> > On Tue, 10 Dec 2019 at 11:06, Keerthy <j-keerthy@ti.com> wrote:
> >>
> >>
> >>
> >> On 10/12/19 3:31 pm, Ard Biesheuvel wrote:
> >>> Hello Keerthy,
> >>>
> >>> On Tue, 10 Dec 2019 at 10:35, Keerthy <j-keerthy@ti.com> 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@linaro.org>
> >>>> 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.
>
Could you elaborate? There is no such thing as an inverse *key*, only
an inverse *key schedule* which is used for the Equivalent Inverse
Cipher.
AES-192 expands the 24 byte key to 13 round keys consisting of 4
32-bit words each, and so the algorithm does not actually use the
contents of slots 52 and up in this case.
> 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
>
The old code does the following for AES-192
#define loop6(i) do { \
t = ror32(t, 8); \
t = ls_box(t) ^ rco_tab[i]; \
t ^= ctx->key_enc[6 * i]; \
ctx->key_enc[6 * i + 6] = t; \
t ^= ctx->key_enc[6 * i + 1]; \
ctx->key_enc[6 * i + 7] = t; \
t ^= ctx->key_enc[6 * i + 2]; \
ctx->key_enc[6 * i + 8] = t; \
t ^= ctx->key_enc[6 * i + 3]; \
ctx->key_enc[6 * i + 9] = t; \
t ^= ctx->key_enc[6 * i + 4]; \
ctx->key_enc[6 * i + 10] = t; \
t ^= ctx->key_enc[6 * i + 5]; \
ctx->key_enc[6 * i + 11] = t; \
} while (0)
case AES_KEYSIZE_192:
ctx->key_enc[4] = get_unaligned_le32(in_key + 16);
t = ctx->key_enc[5] = get_unaligned_le32(in_key + 20);
for (i = 0; i < 8; ++i)
loop6(i);
break;
so while it happens to populate slots 52 and 53 as well (when i == 7),
the AES spec does not actually cover this, given that those values are
not actually used in the computation (and I am at a loss understanding
why it should make a difference in your case).
In any case, you can work around this by calculating the missing
values in your driver's expand_key() routine,
ctx.key_enc[52] = ctx.key_enc[51] ^ ctx.key_enc[46];
ctx.key_enc[53] = ctx.key_enc[52] ^ ctx.key_enc[47];
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: aes_expandkey giving wrong expanded keys over crypto_aes_expand_key(older deprecated implementation under aes_generic)
2019-12-10 13:53 ` Ard Biesheuvel
@ 2019-12-11 6:22 ` Keerthy
0 siblings, 0 replies; 7+ messages in thread
From: Keerthy @ 2019-12-11 6:22 UTC (permalink / raw)
To: Ard Biesheuvel
Cc: open list:HARDWARE RANDOM NUMBER GENERATOR CORE, Kristo, Tero,
Herbert Xu
[-- Attachment #1: Type: text/plain, Size: 5445 bytes --]
On 10/12/19 7:23 pm, Ard Biesheuvel wrote:
> On Tue, 10 Dec 2019 at 12:04, Keerthy <j-keerthy@ti.com> wrote:
>>
>>
>>
>> On 10/12/19 3:37 pm, Ard Biesheuvel wrote:
>>> On Tue, 10 Dec 2019 at 11:06, Keerthy <j-keerthy@ti.com> wrote:
>>>>
>>>>
>>>>
>>>> On 10/12/19 3:31 pm, Ard Biesheuvel wrote:
>>>>> Hello Keerthy,
>>>>>
>>>>> On Tue, 10 Dec 2019 at 10:35, Keerthy <j-keerthy@ti.com> 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@linaro.org>
>>>>>> 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.
>>
>
> Could you elaborate? There is no such thing as an inverse *key*, only
> an inverse *key schedule* which is used for the Equivalent Inverse
> Cipher.
Sorry i was a bit unclear.
>
> AES-192 expands the 24 byte key to 13 round keys consisting of 4
> 32-bit words each, and so the algorithm does not actually use the
> contents of slots 52 and up in this case.
>
>> 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
>>
>
> The old code does the following for AES-192
>
> #define loop6(i) do { \
> t = ror32(t, 8); \
> t = ls_box(t) ^ rco_tab[i]; \
> t ^= ctx->key_enc[6 * i]; \
> ctx->key_enc[6 * i + 6] = t; \
> t ^= ctx->key_enc[6 * i + 1]; \
> ctx->key_enc[6 * i + 7] = t; \
> t ^= ctx->key_enc[6 * i + 2]; \
> ctx->key_enc[6 * i + 8] = t; \
> t ^= ctx->key_enc[6 * i + 3]; \
> ctx->key_enc[6 * i + 9] = t; \
> t ^= ctx->key_enc[6 * i + 4]; \
> ctx->key_enc[6 * i + 10] = t; \
> t ^= ctx->key_enc[6 * i + 5]; \
> ctx->key_enc[6 * i + 11] = t; \
> } while (0)
>
> case AES_KEYSIZE_192:
> ctx->key_enc[4] = get_unaligned_le32(in_key + 16);
> t = ctx->key_enc[5] = get_unaligned_le32(in_key + 20);
> for (i = 0; i < 8; ++i)
> loop6(i);
> break;
>
> so while it happens to populate slots 52 and 53 as well (when i == 7),
> the AES spec does not actually cover this, given that those values are
> not actually used in the computation (and I am at a loss understanding
> why it should make a difference in your case).
>
> In any case, you can work around this by calculating the missing
> values in your driver's expand_key() routine,
>
> ctx.key_enc[52] = ctx.key_enc[51] ^ ctx.key_enc[46];
> ctx.key_enc[53] = ctx.key_enc[52] ^ ctx.key_enc[47];
Thanks a lot for the detailed explanation.
Thanks a lot Ard. The above work around gets it working on my hardware
for 24 byte keys. I will dig more details on that.
Best Regards,
Keerthy
>
[-- Attachment #2: pEpkey.asc --]
[-- Type: application/pgp-keys, Size: 9065 bytes --]
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2019-12-11 6:22 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-12-10 9:35 aes_expandkey giving wrong expanded keys over crypto_aes_expand_key(older deprecated implementation under aes_generic) Keerthy
2019-12-10 10:01 ` Ard Biesheuvel
2019-12-10 10:06 ` Keerthy
2019-12-10 10:07 ` Ard Biesheuvel
2019-12-10 11:04 ` Keerthy
2019-12-10 13:53 ` Ard Biesheuvel
2019-12-11 6:22 ` Keerthy
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.