Using a separate PRNG state for each origin will ensure that entropy is reused (since all of them will need to seed from the same master PRNG). This is bad.
Not seeding them from the same master PRNG would reduce the entropy available in each state. As was the case with Netscape Navigator in the early 2000s, this would be worse. This proposal also has the potential to worse-than-negate the perceived security benefit, as the same sequence of operations without additional entropy being stirred in will result in the same PRNG sequences, potentially leading to the same keystream being used multiple times. This has the potential to be worse still. My thought is that the entire crypto API should be exposed to Javascript, while ensuring that approval for use of private keys (the only persistent value store) is always obtained through the same type of mechanism as is used to authorize the display of passwords Passwords are, to be honest, a lot more common and thus a lot more valuable than private keys in today's consumer world. What's the threat model? When's the last time it was reviewed? The new Mozilla CA requirements (possibly via the Basic Requirements) mandate threat-model review annually. Will Mozilla adhere to the same rules it enforces against external entities? Mozilla is trusted more than any of its CA program members, by definition -- as Mozilla has the potential to list and de-list any CA unilaterally, it is the true Root of Trust. -Kyle H On Tue, Jul 26, 2011 at 1:30 PM, Brian Smith <bsm...@mozilla.com> 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? 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; 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. > > Thanks, > Brian > -- > dev-tech-crypto mailing list > dev-tech-crypto@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-tech-crypto > -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
