From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.saout.de ([127.0.0.1]) by localhost (mail.saout.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gMQZUxJrSS6F for ; Sun, 10 Jul 2011 20:17:10 +0200 (CEST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by mail.saout.de (Postfix) with ESMTP for ; Sun, 10 Jul 2011 20:17:09 +0200 (CEST) Message-ID: <4E19ECA0.6070508@redhat.com> Date: Sun, 10 Jul 2011 20:17:04 +0200 From: Milan Broz MIME-Version: 1.0 References: <4E19D356.7020504@gmail.com> In-Reply-To: <4E19D356.7020504@gmail.com> Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Re: [dm-crypt] MK Digest Size List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: =?ISO-8859-1?Q?Jorge_F=E1bregas?= Cc: dm-crypt@saout.de On 07/10/2011 06:29 PM, Jorge F=E1bregas wrote: > I'm new to DM-Crypt/LUKS and I'm wondering why is it that, when I format > a partition (luksFormat) using --hash sha256, I still get to see 20 HEX > characters (160 bits) for the MK digest? Shouldn't I see 32 HEX chars > (256 bits)? Or is that sha256 is used in the PBKDF2 process but the > function is instructed to deliver just 160 bits? Yes, it uses sha256 but only first 20 bytes is stored. This is limitation of the current LUKS on-disk header (20 bytes was fixed length of SHA1). MK digest is just for verification that decrypted key is correct, 20 bytes is enough for that. > One final thing just to make sure: is the algorithm that appears under > "Hash spec" in the header..is this the same hash-algorithm used (along > with PBKDF2) for the user-keys? as well as the one used with PBKDF2 for > the MK digest? Yes, hash algorithm in LUKS header is used in PBKDF2 and AF splitter. > The man page says for the hash option: ...used in LUKS key setup > scheme and volume key digest. So it appears that "Hash spec" is used > for both...but then, I don't understand why I get just 160 bits when I > specify sha256 :( See above, header structure is fixed, change would mean binary incompatibil= ity. Only MK digest is limited here, in all other cases it uses real length of hash. Milan