[whatwg] Cryptographically strong random numbers

Shabsi Walfish 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
of /dev/random.

Shabsi

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
> https://mail.mozilla.org/listinfo/es-discuss
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20110214/25fa2de1/attachment.html>


More information about the es-discuss mailing list