From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <mbroz@redhat.com>
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28])
	by mail.saout.de (Postfix) with ESMTP
	for <dm-crypt@saout.de>; Mon, 25 Jan 2010 12:25:05 +0100 (CET)
Received: from int-mx04.intmail.prod.int.phx2.redhat.com
	(int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.17])
	by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id o0PBP4QX007989
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK)
	for <dm-crypt@saout.de>; Mon, 25 Jan 2010 06:25:04 -0500
Received: from [10.34.32.183] (mazybook.englab.brq.redhat.com [10.34.32.183])
	by int-mx04.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with
	ESMTP id o0PBP2Sq009392
	for <dm-crypt@saout.de>; Mon, 25 Jan 2010 06:25:03 -0500
Message-ID: <4B5D7F8E.1090202@redhat.com>
Date: Mon, 25 Jan 2010 12:25:02 +0100
From: Milan Broz <mbroz@redhat.com>
MIME-Version: 1.0
References: <cf657bae1001232217k2c85fd25ldb904e263ea9a7f0@mail.gmail.com>	<4B5C25F2.9080607@redhat.com>
	<20100124131101.GA19254@tansi.org>	<20100124140205.GA22492@fancy-poultry.org>
	<20100124230354.GA24786@tansi.org>
In-Reply-To: <20100124230354.GA24786@tansi.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [dm-crypt] Entropy available for luksFormat during	GNU/Linux
 installs
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 01/25/2010 12:03 AM, Arno Wagner wrote:
> On Sun, Jan 24, 2010 at 03:02:05PM +0100, Heinz Diehl wrote:
>> On 24.01.2010, Arno Wagner wrote: 
>>
>>> "As  a  general rule,  /dev/urandom  should  be  used  for everything 
>>>  except long-lived GPG/SSL/SSH keys."


cryptsetup now depends on gcrypt, I will probably rewrite random source
to use gcrypt random generators
(its RNG can use both /dev/random and /dev/urandom for seeding)

In LUKS case, there are four places which need random data:

- volume (master) key generation
- volume key digest salt and password salt
- anti-forensic split for keyslot obfuscation
- safe wipe

we are talking only only the first (master key) case here, right?

Any known problem why not to use gcrypt RNG?
(It should internally wrap possible waiting for enugh entropy,
FIPS mode etc. No need to duplicate code in cryptsetup.)

Milan