On Wed, Feb 03, 2010 at 11:45:02AM +1100, Roscoe wrote: > On Mon, Jan 25, 2010 at 10:25 PM, Milan Broz <mbroz@xxxxxxxxxx> 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@xxxxxxxx > http://www.saout.de/mailman/listinfo/dm-crypt > -- Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: arno@xxxxxxxxxxx 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 _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
