Re: FIPS requirements changing in 2013?
From: Dave Tubbs tu...@moorglade.com Greetings, We're utilizing NSS and will be submitting a Linux-based hardware platform for FIPS certification. The FIPS/CC organization we're working with is telling us that the FIPS requirements will change in 2013. I'm wondering which NSS versions might support these 2013 specs: 1- For DSA, p = 2048 and q = 224 2- For ECDSA generation, n = 224; for ECDSA verification, n = 160 and n 224 3- RSA key generation = 2048 Just getting spun-up on the NSS code, but thought someone on the list may have some quick answers. Thanks! Have you researched it with the NIST ? -- Dave Multi-AV Scanning Tool - http://multi-av.thespykiller.co.uk http://www.pctipp.ch/downloads/dl/35905.asp -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Protecting PRNG against malicious users / multiple independent PRNG states
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
Re: Protecting PRNG against malicious users / multiple independent PRNG states
On 07/26/2011 03:30 PM, Brian Smith wrote: 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/cryptography@randombit.net/msg00601.html Of course, not everyone agrees with me on this (yet :-) - Marsh -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Protecting PRNG against malicious users / multiple independent PRNG states
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? 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 -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Protecting PRNG against malicious users / multiple independent PRNG states
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
