Re: Protecting PRNG against malicious users / multiple independent PRNG states
Nelson B Bolyard
> 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
Marsh Ray
>
> 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 you believe there is a need to separate the PRNG state or restrict
its output, then you believe there is an attack on the PRNG.
> 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.
Complexity added to PRNGs out of concern for entropy depletion has, on
several notable occasions, introduced bugs which caused PRNGs to fail
badly. OpenSSL, OpenBSD, others.
On the other hand, no one has ever shown a successful attack on a
properly designed and implemented PRNG with even 200 bits of state.
Maybe there's one I haven't heard about, but I've been looking out for
it for some time.
> 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.
I understand the mathematical justifications for it, but I believe that
model no longer reflects reality. We have to be willing to move beyond
certain lessons learned from WWII crypto.
Here's a longer post with my arguments:
http://www.mail-archive.com/crypto...@randombit.net/msg00601.html
Of course, not everyone agrees with me on this (yet :-)
- Marsh
Wan-Teh Chang
> 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
>
I just want to note my objection to this proposal before I forget
again. I won't repeat the arguments given by Nelson Bolyard and Marsh
Ray.
Wan-Teh Chang
Kyle Hamilton
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-tec...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-tech-crypto
>