From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ee0-x232.google.com (mail-ee0-x232.google.com [IPv6:2a00:1450:4013:c00::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mail.saout.de (Postfix) with ESMTPS for ; Sun, 9 Mar 2014 19:03:00 +0100 (CET) Received: by mail-ee0-f50.google.com with SMTP id c13so2678429eek.37 for ; Sun, 09 Mar 2014 11:02:59 -0700 (PDT) Received: from [192.168.2.24] (56.157.broadband5.iol.cz. [88.100.157.56]) by mx.google.com with ESMTPSA id 46sm35039588ees.4.2014.03.09.11.02.57 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 09 Mar 2014 11:02:58 -0700 (PDT) Message-ID: <531CAC7E.2050805@gmail.com> Date: Sun, 09 Mar 2014 19:01:34 +0100 From: Milan Broz MIME-Version: 1.0 References: <20140309174247.GA1752@fancy-poultry.org> In-Reply-To: <20140309174247.GA1752@fancy-poultry.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [dm-crypt] SHAx and LUKS/cryptsetup List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: dm-crypt@saout.de 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.