From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from tansi.org (ns.km10532-04.keymachine.de [87.118.102.195]) by mail.saout.de (Postfix) with ESMTP for ; Wed, 3 Feb 2010 07:19:57 +0100 (CET) Received: from gatewagner.dyndns.org (84-74-164-239.dclient.hispeed.ch [84.74.164.239]) by tansi.org (Postfix) with ESMTP id D58264250002 for ; Wed, 3 Feb 2010 07:19:56 +0100 (CET) Date: Wed, 3 Feb 2010 07:21:13 +0100 From: Arno Wagner Message-ID: <20100203062112.GA29960@tansi.org> References: <4B5C25F2.9080607@redhat.com> <20100124131101.GA19254@tansi.org> <20100124140205.GA22492@fancy-poultry.org> <20100124230354.GA24786@tansi.org> <4B5D7F8E.1090202@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: Re: [dm-crypt] Entropy available for luksFormat during GNU/Linux installs List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: dm-crypt@saout.de On Wed, Feb 03, 2010 at 11:45:02AM +1100, Roscoe wrote: > On Mon, Jan 25, 2010 at 10:25 PM, Milan Broz wrote: > > > > 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? > > Yes. > > > 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.) > > What does using the gcrypt RNG get us? As it's a PRNG that's using > /dev/[u]random (in our case) as a source of entropy. I presume it's > security hinges on the source. > > Thus we're introducing another layer and consequently more complexity > and more room for mistakes to be made, but to what benefit? I think the benefit would be that we could set a quantum of entropy to get from /dev/random and then continue with our own (well, gcrypt's) PRNG on top. The problem with using /dev/random diorectly is that it is only suitable for low amounts of needed bits. The problem with /dev/urandom is that it will give you any amount of bist even if the entopy pool is empty and there is no old seed. The gcrypt PRNG initialized from /dev/random would eleminate both issues, provided that it gets enough initial entropy from /dev/random. > Regarding the original premise of the thread, a feature that could > relax those worried about Linux's RNG implementation, is the option to > have the master key derived from whatever source of random bits that > cryptsetup uses, XORed with user specified randomness. Actually that schould be hashed together with a crypto-hash. You may lose entopy otherwise. > The user specified random bits would be prompting the user to pound > the keyboard, then it being feed through PBKDF2 to generate a stream > of sufficient length (we won't hit dkLen). You can use /dev/random directly instead, it already has this functionality. It will take entropy from the keys and, more importantly, from the timing. Arno > Just a thought. > > Regards, > > -- Roscoe > _______________________________________________ > dm-crypt mailing list > dm-crypt@saout.de > http://www.saout.de/mailman/listinfo/dm-crypt > -- Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: arno@wagner.name GnuPG: ID: 1E25338F FP: 0C30 5782 9D93 F785 E79C 0296 797F 6B50 1E25 338F ---- Cuddly UI's are the manifestation of wishful thinking. -- Dylan Evans If it's in the news, don't worry about it. The very definition of "news" is "something that hardly ever happens." -- Bruce Schneier