SHAx and LUKS/cryptsetup
Hi,
while experimenting with LUKS/dmcrypt, I prepared a partition using "-h ripemd160 -c aes-xts-plain64". LuksDump shows:
Version: 1 Cipher name: aes Cipher mode: xts-plain64 Hash spec: ripemd160
However, lsmod shows that both sha1_generic and sha1_ssse3 modules are loaded. So I did a reboot without touching the encrypted device, and there was no SHAx module loaded. After accessing the encrypted drive it was, hence this is clearly the cause that these modules get loaded.
My question: why are there any SHA1 modules loaded when then encrypted drive is NOT using it?
Quoted 10 lines · Heinz Diehl
Hi,
while experimenting with LUKS/dmcrypt, I prepared a partition using "-h ripemd160 -c aes-xts-plain64". LuksDump shows:
Version: 1 Cipher name: aes Cipher mode: xts-plain64 Hash spec: ripemd160
Quoted 7 lines
However, lsmod shows that both
sha1_genericandsha1_ssse3modules are loaded. So I did a reboot without touching the encrypted device, and there was no SHAx module loaded. After accessing the encrypted drive it was, hence this is clearly the cause that these modules get loaded.My question: why are there any SHA1 modules loaded when then encrypted drive is NOT using it?
Probably some dependence inside kernel, cryptsetup should not cause loading of these modules (moreover it uses hash from userspace gcrypt for LUKS header processing, not from kernel).
Probably trace which exact command caused it, maybe there is some sha checksum somewhere triggering it. Isn't it filesystem on top loading it?
How exactly do you activate device and "touch" it?
Milan
p.s.
If you are using kernel backend (not gcrypt one), sha1 is used as test that interface works. It was the simple way at that time. So in this case it is cryptsetup causing it ;-) Maybe it could by changed now by some more clever test.
Quoted 1 line · Milan Broz
If you are using kernel backend (not gcrypt one)
I do :-)
Quoted 1 line
sha1 is used as test that interface works.
Ok, all good! So this is it. Thanks a lot!
Quoted 9 lines · Heinz Diehl
Quoted 1 line · Milan Broz
If you are using kernel backend (not gcrypt one)
I do :-)
Quoted 1 line
sha1 is used as test that interface works.
Ok, all good! So this is it. Thanks a lot!
Just to clarity it little bit:
Kernel userspace crypto API was (and still is)
quite undocumented, and testing SHA1 (which is mandatory for LUKS backend support) was the simplest way how
to verify kernel backend works reliably.
(In some kernel versions it was impossible to check if just algorithm is missing or the whole kernel socket interface is not available.)
It actually does not compute any sha1 hash, it just tries to initialize it.
BTW I found some problems with kernel backend so use with care.
One problem is e.g. backend cannot use longer key for HMAC than 20480 bytes (at least on my 32bit VM), which can cause problems for larger keyfiles in PBKDF2.
I have workaround for this but will need some time to finish it (I do not want to touch internal PBKDF2 without adding test vectors and other tests.)
Milan
Quoted 7 lines · Milan Broz
Quoted 6 lines · Heinz Diehl
Quoted 1 line · Milan Broz
If you are using kernel backend (not gcrypt one)
I do :-)
Quoted 7 lines
Quoted 3 lines
Quoted 1 line
sha1 is used as test that interface works.
Ok, all good! So this is it. Thanks a lot!
Just to clarity it little bit:
Kernel userspace crypto API was (and still is) quite undocumented,
This is one thing I really do not understand. Doing crypto right is already hard. With bad documentation it gets worse. Yet the documentation for kernel, OpenSSL, commercial libraries I have looked at, Java API, etc. is bad. (for Java so bad that recently 30'000 Apps on Android were insecure).
I really do not get it. Systematic sabotage of the documentation seems unlikely, even after Snowden, so I can only conclude many people implementing crypto have a problem writing documentation.
Quoted 10 lines
and testing SHA1 (which is mandatory
for LUKS backend support) was the simplest way how
to verify kernel backend works reliably.
(In some kernel versions it was impossible to check if just algorithm is missing or the whole kernel socket interface is not available.)It actually does not compute any sha1 hash, it just tries to initialize it.
BTW I found some problems with kernel backend so use with care.
Bad documentation and unreliable. Urgh.
Quoted 7 lines
One problem is e.g. backend cannot use longer key for HMAC than 20480 bytes (at least on my 32bit VM), which can cause problems for larger keyfiles in PBKDF2.
I have workaround for this but will need some time to finish it (I do not want to touch internal PBKDF2 without adding test vectors and other tests.)
Very sensible. I completely support this approach.
Arno
Quoted 6 lines
Milan
_______________________________________________
dm-crypt mailing list
[email protected]
http://www.saout.de/mailman/listinfo/dm-crypt
Signature · 4 lines
Arno Wagner, Dr. sc. techn., Dipl. Inform., Email: [email protected] GnuPG: ID: CB5D9718 FP: 12D6 C03B 1B30 33BB 13CF B774 E35C 5FA1 CB5D 9718 ---- A good decision is based on knowledge and not on numbers. - Plato