Re: [dm-crypt] Entropy available for luksFormat during GNU/Linux installs

[Arno Wagner <arno@wagner.name>]

On Wed, Feb 03, 2010 at 11:45:02AM +1100, Roscoe wrote:
> On Mon, Jan 25, 2010 at 10:25 PM, Milan Broz <mbroz@redhat.com> 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