[whatwg] Cryptographically strong random numbers
shabsi at google.com
Mon Feb 14 15:43:04 PST 2011
OpenSSL is not exactly a reliable source of cryptographic best practices. :)
In any case, see here http://linux.die.net/man/4/urandom :
When read, the */dev/random* device will only return random bytes within the
estimated number of bits of noise in the entropy pool. */dev/random* should
be suitable for uses that need very high quality randomness such as one-time
pad or key generation. When the entropy pool is empty, reads from *
/dev/random* will block until additional environmental noise is gathered.
A read from the */dev/urandom* device will not block waiting for more
entropy. As a result, if there is not sufficient entropy in the entropy
pool, the returned values are theoretically vulnerable to a cryptographic
attack on the algorithms used by the driver. Knowledge of how to do this is
not available in the current non-classified literature, but it is
theoretically possible that such an attack may exist. If this is a concern
in your application, use */dev/random* instead.
To be honest, I'm surprised if even OpenSSL reads from /dev/urandom instead
On Mon, Feb 14, 2011 at 3:36 PM, Glenn Maynard <glenn at zewt.org> wrote:
> On Mon, Feb 14, 2011 at 5:46 PM, Shabsi Walfish <shabsi at google.com> wrote:
>> This depends on what you consider to be the basic use case. Generating
>> long-lived cryptographic keys absolutely requires high quality entropy... if
>> you are only generating short-lived authenticators (that are not used for
>> encryption) then you could get away with weaker entropy. You will get the
>> most mileage out of this feature if it can be used to generate encryption
>> keys, or long-lived signing keys.
> OpenSSL gets randomness for generating keys by reading /dev/urandom. It
> doesn't seem to do any other tricks, like reading
> /proc/sys/kernel/random/entropy_avail. That at least suggests it's
> sufficient for securely generating keys, without more complex APIs like
> exposing the amount of entropy that was available.
> Glenn Maynard
> es-discuss mailing list
> es-discuss at mozilla.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss