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 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.