[whatwg] Cryptographically strong random numbers

Shabsi Walfish shabsi at google.com
Mon Feb 14 15:58:39 PST 2011

On Mon, Feb 14, 2011 at 3:49 PM, Bill Frantz <frantz at pwpconsult.com> wrote:

> On 2/14/11 at 2:46 PM, shabsi at google.com (Shabsi Walfish) 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.
> [Greetings to old friends and new. And I hope I've properly subscribed to
> all the right lists...]
> I have a big problem with concepts such as "using up entropy", and "high
> quality entropy is needed." I belong to the school that says, "If I have 160
> unguessable bits and can keep them secret, I can stretch them and remain
> secure for ever." Now there are some issues with this statement:

I don't disagree with this -- however, I would say the problem is that
urandom may not return 160 "unguessable" bits to start with. Unguessable, of
course, actually means "extremely difficult to predict with better than
probability 1/2, conditioned on all previously observable information (such
as approximate system time, process ids, etc.)". In any case, I was simply
suggesting it would be nice to make available information about the quality
of the entropy being returned by /dev/urandom, which is either going to be
good (because the entropy pool was full) or _possibly_ not good (perhaps
because the entropy pool hasn't ever filled up yet).


>  * I don't really trust my stretching algorithms, based on
>    secure hashes, to not leak some tiny fraction of the
>    unguessable bits.
>  * Keeping any secret is difficult.
>  * Getting unguessable bits is a hard problem.
>  * 160 may be too small.
> Because of these issues, modern secure random number generators add batches
> of new unguessable bits from time to time.
> This line of thinking leads me to say that /dev/urandom, and its Windows
> cousin, is good enough for any practical use. Ensuring that the seed for
> /dev/urandom is indeed unguessable is a problem for the OS, not the language
> run-time.
> For ECMAscript/Javascript or whatever this group calls the language, I
> suggest:
>  (1) Build a routine that returns /dev/urandom data to the
>  caller. Implement this routine fairly quickly.
>  (2) At a more leisurely pace, build a crypto API and implement
>  it in the language. After the usability bugs are worked out of
>  the API, standardize it. If more performance is needed, perhaps
>  a platform dependent issue, build higher speed implementations
>  of the standard.
> [Historically, a number of crypto-based APIs have failed because developers
> could not figure out how to use them. Getting the usability right is
> probably the hardest part of designing the API.
> Cheers - Bill
> -----------------------------------------------------------------------
> Bill Frantz        |The nice thing about standards| Periwinkle
>  <%28408%29356-8506>(408)356-8506      |is there are so many to choose|
> 16345 Englewood Ave
> www.pwpconsult.com |from.   - Andrew Tannenbaum   | Los Gatos, CA 95032
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20110214/0f97ea39/attachment.html>

More information about the es-discuss mailing list