Log in

No account? Create an account

Thu, Jul. 9th, 2009, 03:24 pm
Someone at Mozilla Foundation needs to be fired

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'll say the exact same thing.

Once a computer has collected a small number of 'true' random bits (maybe it's 128, maybe it's 256, but regardless it's small) there's no need whatsoever for it to block on collecting more 'random' numbers. A pseudorandom number generator based on AES will be able to generate random numbers based on that seed until the end of the universe and noone constrained by the laws of physics and math will ever be able to tell the difference between that and 'true' random numbers. This is extremely well established cryptography. To require 'true' random numbers is, to use an apt analogy, wankery. It does not, and cannot, do anything to improve security, and it mostly just causes huge amounts of pain. It is (and I repeat myself, because I have a hunch people will think I'm glossing over some nuance here) of no benefit whatsoever.

My advice to the Mozilla foundation (and again, this is my reasoned opinion, not said in anger, and I won't be changing my mind later): find out who was responsible for this policy of requiring lots of 'true' random numbers, and fire them. Fire them today. They have demonstrated gross incompetence, a total lack of understanding of the very most basic concepts in security.

Some people might think that if I knew more about who was behind this and what their specific motivations are, then that might change my mind. That is incorrect. The security field is filled with people who to non-experts seem very impressive and knowledgeable, especially when they're advocating, and even moreso demanding, very painful and difficult things in the name of security. Most of these people are frauds. I have had it with paying homage to the concept of impartiality when discussing these peoples's opinions. If someone spouts a bunch of technical mumbo-jumbo to bring the conversation to a place which a lay person has trouble understanding, then they may be able to make the argument be based on pure rhetoric, but gross incompetence is still gross incompetence, and despite having found an effective way to bullshit their way through, they're still wrong.

Fri, Jul. 10th, 2009 12:56 am (UTC)

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]) = ...

Fri, Jul. 10th, 2009 02:32 am (UTC)

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.

Fri, Jul. 10th, 2009 02:53 am (UTC)

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.

Fri, Jul. 10th, 2009 08:11 am (UTC)

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.

Fri, Jul. 10th, 2009 03:11 pm (UTC)

If a source isn't able to provide 256 random bits reasonably quickly, it probably isn't worth using as a source at all.

Fri, Jul. 10th, 2009 04:59 am (UTC)

Here I'm in agreement with Bram (and the original code). The RNG state should never be saved to disk.

Reseeding either from raw entropy, or from a master PRNG as I described is simply to help mitigate some state capture attacks yes.

Most concerning are attacks where the PRNG is shared between all tabs/windows, and an attacker in one could predict the PRNG data used for other windows (assuming a predicable PRNG, which has happened before).

Fri, Jul. 10th, 2009 07:31 am (UTC)

By 'predictable PRNG' you mean one whose state can be guessed from access to the pseudorandom number stream, rather than requiring access to internal PRNG state information? I know simple PRNGs have been attacked this way, but I thought Bram's point was that this sort of predictability could be reliably avoided with known CSPRNG designs.

Fri, Jul. 10th, 2009 03:36 pm (UTC)

In my other comment, I noted that if a master PRNG was being used to seed other PRNGs, then specific properties were required - I've seen cases where they failed to heed that requirement, and thus could be attacked by simply having an earlier copy of the PRNG that you iterated to gain the data that would be used later, and then replay it. In doing so, you don't need any internal state, just capturing the data further from another instance before it's used in the target PRNG.

Fri, Jul. 10th, 2009 02:57 am (UTC)

Best practices for random number generation are beyond the scope of this post - my point is that the current NSS implementation is most definitely not best practices, not even conservative behavior. It's just stupid.

Sun, Aug. 2nd, 2009 04:38 pm (UTC)
trs80 [typekey.com]

Yeah, the log for the file shows the "get entropy from system files" algorithm has been there since before 2001, when the file was moved to its current location: http://bonsai.mozilla.org/cvslog.cgi?file=mozilla/security/nss/lib/freebl/win_rand.c I suspect it only got shit when wtc@google.com changed it to recurse into directories in revision 1.18. NSS is just awful code though - it expects to be initialised once per application, which makes it useless for libraries.

Sun, Aug. 2nd, 2009 04:49 pm (UTC)
trs80 [typekey.com]

Reading the linked bug shows that the recurse directories code was originally for WindowsCE where entropy was at a premium, and it was then generalised to all Windows versions. Presumably WinCE devices have flash so scanning directories is cheap, which is not the case for hard drives in PCs. Anyway, if you're still looking for someone to blame, Brad Lassey is a Mozilla employee who works on Fennec, the browser for WinCE, who wrote the patch and obviously has no security experience, but was just trying to fix the bug on his platform, but neglected to test on others.