On Mon, Feb 14, 2011 at 3:49 PM, Bill Frantz <[email protected]> wrote:
> On 2/14/11 at 2:46 PM, [email protected] (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). Shabsi > > * 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 > >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
