On 9.3.2014 18:42, Heinz Diehl wrote:
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?
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. _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
