On 2011-07-26 13:30 PDT, Brian Smith wrote: > Mozilla would like to expose a secure PRNG (basically, a wrapper around > PK11_GenerateRandom) to JavaScript content: > https://bugzilla.mozilla.org/show_bug.cgi?id=440046 > > There is some agreement that we should maintain separate PRNG state for > each origin (roughly: domain name), and that all those states should be > separate from the PRNG state used internally. PK11_GenerateRandom > currently shares the PRNG state across all callers. Does anybody > disagree about this separation being necessary?
Yes. > If not, then we (Mozilla) would to change pk11wrap so that we can > control these separate PRNG states. (If this is really important, then > eventually this consideration for separate contexts will need to be > made for all APIs that use the PRNG that we plan to expose to > JavaScript, such as PK11_GenerateKeyPair.) However, I am not sure if > these separate states are really necessary; I'm pretty certain they are not necessary. There might be other reasons to have multiple parallel DRBGs, such as parallel performance on multi-core CPUs. > if they were, then wouldn't it be better to maintain separate states > for each SSL connection in libssl too? > > There was also some concern raised about preventing unnecessary > depletion of entropy, while still providing good randomness to the > calling JavaScript code. Suggestions for this would be much > appreciated. My current thought is that we should restrict the > JavaScript API such that a origin can only acquire a certain > (relatively small) quantity of output from the PRNG. The current NIST-approved DRBG is claimed by NIST to not require re-seeding until 2^48 (~256 trillion) requests have been fulfilled, each requesting up to 2^16 bytes. See table 2, p. 34-45 of http://csrc.nist.gov/publications/nistpubs/800-90/SP800-90revised_March2007.pdf > > Thanks, Brian -- /Nelson Bolyard -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
