Someone at Mozilla Foundation needs to be fired

[bramcohen]

Somebody at Mozilla decided they need lots of 'true' random numbers.

My patience for this subject completely ran out about five years ago, so this post is going to show a complete lack of diplomacy. I would like to emphasize, in advance, that this is my honest, reasoned opinion, not said in anger, and that if you ask my opinion again in the future I

Comments

[ciphergoth]

Agreed entirely; this business drives me crazy!

(edit: though I don't think I'd advocate firing anyone!)

[bramcohen]

In my experience, it's best to fire people early and often

[bramcohen]

Best practices for maintaining a random number pool are an interesting subject, and way beyond the scope of what I wanted to cover here. The short of it is that it can be done right, and the attacks you mention can be stopped without having to carefully vet the data being mixed in, but I have little confidence that there weren't other idiocies in this release, given the big central obvious one.

[codetoad]

There's no evidence, based on that linked to blog, that they didn't understand what you're saying. A stupid implementation, for sure. But I'm guessing that:

1) Each new window is kinda like a new process, or something. So FF restarts all the security machinery, including random number generation.

2) They may have just been adding everything together to get one random number seed.

[robbat2]

Hey, it's at least better than the Netscape RNG attack from 1995.
Parts of that are still evident in the NSS codebase.

In one addendum to the above, just remember to reseed your generator occasionally, or use separate generators for different sites. I think seeding them from the master generator should be safe as long as your generator is not purely iterative on the seed and mixes it in properly.

That is, given generator G with seed x, the following should not return related series:
G(G(x)[0]) = ...
G(G(x)[1]) = ...

[oddments]

Reseeding for the same sort of 'best practices' reasons that motivate switching encryption keys periodically, so that capturing state once doesn't permanently compromise the RNG?

I notice that the Firefox design described seems to be built on the assumption that any RNG state saved between sessions is readily compromised, while the state during operation and the disposition of the temp files are not.

[bramcohen]

If you'll read carefully, you'll see that I didn't say blocking should never happen, just that it shouldn't happen after some threshold of amount of entropy has been pulled into the pool.

[oddments]

I saw that, and you offered this constraint as an alternative to a startup delay. The two ways to solve the described problem based on that constraint are by storing state between subsequent startups (so that the delay occurs only at install time), or by reducing the amount of entropy gathered at startup, which presupposes the NSS designers gathered way too much.

There are two other ways I can see that the NSS design might have ended up being too slow, though: gathering entropy from a source with a potentially very slow response, and gathering it from a source that's potentially not very random. If they're relying on reading everything in temporary file caches, it's possible they're encountering all three issues at once.

NSS employment

[hoserhead]

Nobody at the Mozilla Foundation works on NSS. Nobody at the Mozilla Corporation works on NSS, either. For that, you can blame/praise Red Hat and Sun employees.

Re: NSS employment

[illiterat]

I find it hard to believe that NSS itself is trawling the filesystem, so I'd assume that this is coming from some mozilla code which is just calling a "seed PRNG" NSS API.

Re: NSS employment

[robbat2]

It DOES seem to be NSS :-(
nss-3.12.3/mozilla/security/nss/lib/freebl/win_rand.c:
There's void RNG_SystemInfoForRNG(void):
352 // now let's do some files
353 ReadSystemFiles();
Which goes to EnumSystemFiles, which has this gem:

181 static BOOL
182 EnumSystemFiles(Handler func)
183 {
184 PRUnichar szSysDir[_MAX_PATH];
185 static const int folders[] = {
186 CSIDL_BITBUCKET,
187 CSIDL_RECENT,
188 #ifndef WINCE
189 CSIDL_INTERNET_CACHE,
190 CSIDL_COMPUTERSNEARME,
191 CSIDL_HISTORY,
192 #endif
193 0
194 };

which comes from some windows header, possibly shlobj.h if the comments amongst the headers are correct.

The RNG_SystemInfoForRNG function itself is very interesting in what they take entropy from. Bad sources in my opinion.

Re: NSS employment

[sysprv]

Can't find anything about RedHat or Sun on the informal history here: http://www.mozilla.org/projects/security/pki/nss/history.html

Or were you thinking of glibc's nss?