[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: Patch: new random pseudodevice
> -----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;
> 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).
Main Index |
Thread Index |