From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <jorge.fabregas@gmail.com>
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 KAw2DCwZ7ZkF for <dm-crypt@saout.de>;
 Sun, 10 Jul 2011 18:59:55 +0200 (CEST)
Received: from mail-yw0-f50.google.com (mail-yw0-f50.google.com
 [209.85.213.50]) (using TLSv1 with cipher RC4-SHA (128/128 bits))
 (No client certificate requested)
 by mail.saout.de (Postfix) with ESMTPS
 for <dm-crypt@saout.de>; Sun, 10 Jul 2011 18:59:55 +0200 (CEST)
Received: by ywa6 with SMTP id 6so1510425ywa.37
 for <dm-crypt@saout.de>; Sun, 10 Jul 2011 09:59:53 -0700 (PDT)
Message-ID: <4E19DA87.5060000@gmail.com>
Date: Sun, 10 Jul 2011 12:59:51 -0400
From: =?ISO-8859-1?Q?Jorge_F=E1bregas?= <jorge.fabregas@gmail.com>
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: <dm-crypt.saout.de>
List-Unsubscribe: <http://www.saout.de/mailman/options/dm-crypt>,
 <mailto:dm-crypt-request@saout.de?subject=unsubscribe>
List-Archive: <http://www.saout.de/pipermail/dm-crypt>
List-Post: <mailto:dm-crypt@saout.de>
List-Help: <mailto:dm-crypt-request@saout.de?subject=help>
List-Subscribe: <http://www.saout.de/mailman/listinfo/dm-crypt>,
 <mailto:dm-crypt-request@saout.de?subject=subscribe>
To: dm-crypt@saout.de

On 07/10/2011 12:29 PM, Jorge F=E1bregas wrote:
> I still get to see 20 HEX characters (160 bits) for the MK digest? =20

I'm sorry.  I meant 20 pairs of HEX characters (40 chars) as they appear
nicely formatted in the luksDump output.

> Shouldn't I see 32 HEX chars (256 bits)?  =20

Same here (64 hex characters ).

> Or is that sha256 is used in the PBKDF2 process but the function is=20
> instructed to deliver just 160 bits?

Ok, I'm going to try to answer myself as I just read again the latest
specification.  It appears this is the case (just 160 bits even if you
use sha256) because there are just 20 bytes available for "mk-digest" in
the header.

I'm just curious:  is having just 20 bytes for the digest a limitation
here?  Are there any plans to expand this field in the future?


> 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?

Apparently yes.

Sorry for the noise!

Regards,
Jorge