Re: Patch: new random pseudodevice

[Paul Koning <paulkoning%comcast.net@localhost>]

> 
> -----Original Message-----
> From: tech-kern-owner%NetBSD.org@localhost 
> [mailto:tech-kern-owner%NetBSD.org@localhost] On Behalf Of Mouse
> Sent: Friday, December 09, 2011 2:24 PM
> To: tech-security%NetBSD.org@localhost; tech-kern%NetBSD.org@localhost; 
> tech-crypto%NetBSD.org@localhost
> Subject: Re: Patch: new random pseudodevice
> ...
>> I think that, in practice, that is about as close to meeting the 
>> expectations of the application authors as possible.
> 
> As an application author, I'm not sure.  From a point of view of making the 
> device fit the use, I would like to see
> 
> (1) Strong bits suitable for direct use as things like crypto keys.
> Using a PRNG here, even a really good one, is a major fail.  The only time 
> it's acceptable is when the data drawn is no larger than the PRNG key, and 
> then you might as well return the bits directly.

I don't think this is correct.

One thing to keep in mind is that the current standard of quality for a cipher 
is that its output is indistinguishable from a random string (up to a length 
limit, 2^blocksize or 2^(blocksize/2), I'm not sure which).

In IKE, the exchange results in a shared secret value.  The spec explicitly 
recognizes the possibility that the ciphers keys required may need to be longer 
than that, and spells out how to extend the value by using the original value 
with a hash, or in a cipher.  While obviously that doesn't give you the full 
range of values because the input is shorter, the fact that you're using crypto 
mechanisms means that this property doesn't help attack the resulting system.  
In any case, if the PRNG uses a strong mixing function, then that is 
essentially the same sort of system as the extension schemes that IKE approves.

Bruce Scheier discusses this topic far more thoroughly and better in the 
background discussion for Yarrow.  That material is the reason why I stopped 
using /dev/random and switched to /dev/urandom exclusively: Scheier convinced 
me that the stuff that /dev/random does serve no purpose when a source of 
cryptographically strong random bits is needed (so long as the generator is 
originally seeded adequately).

        paul