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? 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. 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). Just a thought. Regards, -- Roscoe _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
