[whatwg] Cryptographically strong random numbers

Bill Frantz frantz at pwpconsult.com
Mon Feb 14 15:49:50 PST 2011

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 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
(408)356-8506      |is there are so many to choose| 16345 
Englewood Ave
www.pwpconsult.com |from.   - Andrew Tannenbaum   | Los Gatos, 
CA 95032

More information about the es-discuss mailing list