[dm-crypt] SHAx and LUKS/cryptsetup

Milan Broz gmazyland at gmail.com
Sun Mar 9 19:01:34 CET 2014

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?


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.

More information about the dm-crypt mailing list