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

[Milan Broz <mbroz@redhat.com>]

On 02/03/2010 01:45 AM, Roscoe wrote:
> On Mon, Jan 25, 2010 at 10:25 PM, Milan Broz <mbroz@redhat.com> wrote:

>> 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.

Yes. But cryptsetup is already based on gcrypt crypto functions.
For RNG:
http://www.gnupg.org/documentation/manuals/gcrypt/Random_002dNumber-Subsystem-Architecture.html

> Thus we're introducing another layer and consequently more complexity
> and more room for mistakes to be made, but to what benefit?

Actually, I think the opposite:-) gcrypt is widely used in several
crypto projects, I know there were reviews etc.
(Note it is crypto library used and developed for GnuPG).
Any crypto implementation, like RNG handling inside cryptsetup
will never be so closely verified.
(And possible mistake here is catastrophic to security - imagine
it will loop because some signal received instead of waiting
for entropy and read all 0 instead of master key.)

> 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).

And exactly this waiting is solved by gcrypt RNG and I do need
to reimplement it in cryptsetup.

Also if the system is in FIPS mode (and there are possible installations
which want this) long term key used for disk encryption must be
generated from RNG (resp. FIPS certified RNG only).
(IOW I want to avoid any post-RNG operation like XOR you mention,
this can bring more problems than it solves IMHO)

Gcrypt is FIPS capable and hides all that self-test machinery needed
for FIPS.

Of course I mean using GCRY_VERY_STRONG_RANDOM which is
intended for long-term key generator.
But for keyslot AF split we need also randomly generated buffer
but now the system can use more relaxed generator.
I cannot simply read /dev/random always and wait for entropy - for these
operations /dev/urandom should be used.
Gcrypt provides nice wrapper for that - gcry_random_bytes* functions.

From my point of view it is more consistent that all crypto related
functions, including secure RNG, are in one library. So cryptsetup
itself handles LUKS operations but no low-level crypto implementations
(hash, ciphers, RNG, etc)
(We have already all that complexity with gcrypt initialisation included.)

In fact, it is not complicated to implement both. But I think that
responsibility for properly initialising RNG can be moved to trusted
crypto library and not try to do it inside the code.
(Maybe quite shifting of responsibility:-)

Milan