From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gmazyland@gmail.com>
Received: from mail-ee0-x229.google.com (mail-ee0-x229.google.com
 [IPv6:2a00:1450:4013:c00::229])
 (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits))
 (No client certificate requested)
 by mail.saout.de (Postfix) with ESMTPS
 for <dm-crypt@saout.de>; Sun,  9 Mar 2014 20:54:29 +0100 (CET)
Received: by mail-ee0-f41.google.com with SMTP id t10so2764325eei.28
 for <dm-crypt@saout.de>; Sun, 09 Mar 2014 12:54:28 -0700 (PDT)
Received: from [192.168.2.24] (56.157.broadband5.iol.cz. [88.100.157.56])
 by mx.google.com with ESMTPSA id x3sm36064446eep.17.2014.03.09.12.54.25
 for <dm-crypt@saout.de>
 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
 Sun, 09 Mar 2014 12:54:26 -0700 (PDT)
Message-ID: <531CC69E.8000300@gmail.com>
Date: Sun, 09 Mar 2014 20:53:02 +0100
From: Milan Broz <gmazyland@gmail.com>
MIME-Version: 1.0
References: <20140309174247.GA1752@fancy-poultry.org>
 <531CAC7E.2050805@gmail.com> <20140309183204.GA2999@fancy-poultry.org>
In-Reply-To: <20140309183204.GA2999@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: <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 9.3.2014 19:32, Heinz Diehl wrote:
> On 09.03.2014, Milan Broz wrote:
>
>> If you are using kernel backend (not gcrypt one)
>
> I do :-)
>
>> sha1 is used as test that interface works.
>
> Ok, all good! So this is it. Thanks a lot!

Just to clarity it little bit:

Kernel userspace crypto API was (and still is)
quite undocumented, and testing SHA1 (which is mandatory
for LUKS backend support) was the simplest way how
to verify kernel backend works reliably.
(In some kernel versions it was impossible to check if just algorithm
is missing or the whole kernel socket interface is not available.)

It actually does not compute any sha1 hash, it just tries
to initialize it.

BTW I found some problems with kernel backend so use with care.

One problem is e.g. backend cannot use longer
key for HMAC than 20480 bytes (at least on my 32bit VM),
which can cause problems for larger keyfiles in PBKDF2.

I have workaround for this but will need some time to finish
it (I do not want to touch internal PBKDF2 without adding test
vectors and other tests.)

Milan