Hi,
after upgrading the kernel from 2.6.12.5 to 2.6.16-rc4, decryption of my disk fails. As I am using the Nehemia's Padlock and aes-cbc-essiv, I guess this is the reason:
(from ChangeLog-2.6.13)
commit 476df259cd577e20379b02a7f7ffd086ea925a83
Author: Herbert Xu <[email protected]>
Date: Wed Jul 6 13:54:09 2005 -0700
[CRYPTO] Update IV correctly for Padlock CBC encryption
When the Padlock does CBC encryption, the memory pointed to by EAX is
not updated at all. Instead, it updates the value of EAX by pointing
it to the last block in the output. Therefore to maintain the correct
semantics we need to copy the IV.
Signed-off-by: Herbert Xu <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
This probably means, that the on-disk format has changed, and the new aes routine can't decrypt my data any more.
The strange thing is: if I disable the padlock driver and use the software-only aes_i586 module, I can read my disk with 2.6.16-rc4. So obviously one of the implementations produces wrong results (they are supposed to do the same thing, right?). So before I try to re-encrypt my disk: which one is doing it right?
Thanks,
Michael
On Tue, Feb 21, 2006 at 01:27:50PM +0100, Michael Heyse wrote:
>
> after upgrading the kernel from 2.6.12.5 to 2.6.16-rc4, decryption of my disk fails. As I am using the Nehemia's Padlock and aes-cbc-essiv, I guess this is the reason:
>
> (from ChangeLog-2.6.13)
> commit 476df259cd577e20379b02a7f7ffd086ea925a83
> Author: Herbert Xu <[email protected]>
> Date: Wed Jul 6 13:54:09 2005 -0700
>
> [CRYPTO] Update IV correctly for Padlock CBC encryption
>
> When the Padlock does CBC encryption, the memory pointed to by EAX is
> not updated at all. Instead, it updates the value of EAX by pointing
> it to the last block in the output. Therefore to maintain the correct
> semantics we need to copy the IV.
I don't think this patch is your problem since it's part of the multiblock
code which doesn't exist in 2.6.12 at all. Of course the multiblock code
itself could be buggy. I'll take a look.
Thanks,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
On Wed, Feb 22, 2006 at 12:31:37PM +1100, herbert wrote:
>
> I don't think this patch is your problem since it's part of the multiblock
> code which doesn't exist in 2.6.12 at all. Of course the multiblock code
> itself could be buggy. I'll take a look.
OK I can't reproduce this. Please send me your dmcrypt setup line so
I can try it here.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Herbert Xu wrote:
> I don't think this patch is your problem since it's part of the multiblock
> code which doesn't exist in 2.6.12 at all. Of course the multiblock code
> itself could be buggy. I'll take a look.
You're right, this doesn't make sense. I tried it with 2.6.15.4, and it works, 2.6.16-rc1 doesn't. In both cases no other AES algorithm than padlock was compiled into the kernel. I hope this helps.
BTW: 2.6.15 gives me a read performance increase of about 50% (hdparm -t) compared to 2.6.12, nice work!!
Michael
Herbert Xu wrote:
> On Wed, Feb 22, 2006 at 12:31:37PM +1100, herbert wrote:
>
>>I don't think this patch is your problem since it's part of the multiblock
>>code which doesn't exist in 2.6.12 at all. Of course the multiblock code
>>itself could be buggy. I'll take a look.
>
>
> OK I can't reproduce this. Please send me your dmcrypt setup line so
> I can try it here.
I'm using the cryptsetup tool (from http://www.saout.de/misc/dm-crypt/):
echo $KEY | cryptsetup -c aes-cbc-essiv:sha256 -h plain -s 256 create data /dev/vg0/data
$KEY contains 32 bytes of binary data. Do you need any other information? Here's all I can think of:
- parition /dev/vg0/data lies on a lvm2 volume group
- this volume group lies on a 4-disk software-raid 5 array
- size of the partition is 300 GB
- padlock aes works on kernel 2.6.15.4 but not on 2.6.16-rc1
- aes_i586 works on all kernels
Thanks,
Michael
I found the problem, it's a typo in drivers/crypto/padlock-aes.c (introduced probably in the "[CRYPTO] Use standard byte order macros wherever possible" patch) and only happens with 256 bit keys.
it says below the "case 32:"
E_KEY[4] = le32_to_cpu(in_key[4]);
E_KEY[5] = le32_to_cpu(in_key[5]);
E_KEY[6] = le32_to_cpu(in_key[6]);
t = E_KEY[7] = le32_to_cpu(in_key[7]);
but it should be
E_KEY[4] = le32_to_cpu(key[4]);
E_KEY[5] = le32_to_cpu(key[5]);
E_KEY[6] = le32_to_cpu(key[6]);
t = E_KEY[7] = le32_to_cpu(key[7]);
Now it's working!
Michael
On Wed, Feb 22, 2006 at 01:32:20PM +0100, Michael Heyse wrote:
>
> but it should be
>
> E_KEY[4] = le32_to_cpu(key[4]);
> E_KEY[5] = le32_to_cpu(key[5]);
> E_KEY[6] = le32_to_cpu(key[6]);
> t = E_KEY[7] = le32_to_cpu(key[7]);
>
> Now it's working!
Well spotted. I've cooked up a patch from your description:
[CRYPTO] padlock: Fix typo that broke 256-bit keys
A typo crept into the le32_to_cpu patch which broke 256-bit keys
in the padlock driver. The following patch based on observations
by Michael Heyse fixes the problem.
Signed-off-by: Herbert Xu <[email protected]>
Thanks Michael,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt