
Randomness Requirements for Security (2005) - Tomte
http://tools.ietf.org/html/rfc4086
======
lisper
Here's all you really need to know about randomness:

1\. You need two things: an entropy source, and a whitener. No entropy source
is perfect, so you need a whitener no matter what. You don't have to do
anything fancy in your whitener. Any cryptographically secure hash function
(like SHA512) will do.

2\. Since you need a whitener no matter what, it doesn't really matter how
good your entropy source is, except insofar as it might take a long time to
collect enough entropy from a very poor source. All that matters is that you
have an accurate lower bound for how much entropy your source actually
provides, and this is the case no matter how good (or bad) your source
actually is. As long as you feed >N bits of entropy into your whitener, you
can safely extract N bits of true randomness out of it.

3\. You don't need more than a few hundred bits of randomness. 128 bits is
enough, 256 is a comfortable margin, 512 is serious overkill. Seed a
cryptographically secure PRNG with a few hundred bits of entropy and you can
safely extract gigabytes of key material out of it.

4\. Because of 1-4, putting a lot of effort into designing and tuning a HWRNG
is pointless. Such a device provides no value over a poor entropy source fed
through a whitener _provided_ you have an accurate lower bound on the entropy
content so you can be sure you have seeded your PRNG with enough initial
entropy.

~~~
tptacek
Which, in case anyone reads this and gets excited about designing their own
CSPRNG, is pretty much exactly what you get from /dev/urandom (or whatever the
kernel CSPRNG is on your platform).

~~~
lisper
Only if you trust your platform devs to get it right. On Linux that's probably
a good bet (and on FreeBSD it's probably an even better bet). But on MacOS or
Windows? There's no way to tell whether a CSPRNG has been compromised by
looking at its output, so you don't have to put on a very thick tinfoil hat to
believe that the probability that these might be compromised somehow is
greater than zero, in which case knowing how to roll your own CSPRNG can be
very handy. At the very least, knowing these things can help you detect snake
oil (like the "measured performance" at
[http://moonbaseotago.com/onerng/theory.html](http://moonbaseotago.com/onerng/theory.html))

~~~
tptacek
OSX's kernel CSPRNG is Yarrow.

Window's CryptGenRandom and derivatives are one of the more well-studied OS
CSPRNGs.

~~~
lisper
And you know this how? Have you actually decompiled the kernel to make sure
that the /dev/urandom driver actually does what the documentation says it
does? If you haven't (and I know that you might actually have done this, but
most people would not have) then you're back to trusting the manufacturer.

BTW, the most likely threat model is not Apple or Microsoft making a stupid
mistake in their PRNG, but rather having made a back-room deal with (say) the
NSA to intentionally back-door /dev/urandom.

~~~
hannob
Some people actually do decompile things to make sure they don't contain
security vulns.

However, if your threat model includes Apple or Microsoft hiding a backdoor in
the OS then you can't use their OS. Designing your own CSPRNG doesn't help
you. If you want that level of security you need to switch to an operating
system you can trust (what that means is a complicated question which probably
includes free software, reproducible builds, transparency logs and then you'll
still end up with hardware you can't trust).

~~~
lisper
> Some people actually do decompile things to make sure they don't contain
> security vulns.

Of course, and tptacek might even be one of them. But most people don't do
this. And if you don't do it yourself, if you rely on someone else who says
that they did it, how do you know you can trust _them_?

This rabbit hole is, of course, as deep as you care to dig it. It's not
possible to function without trusting _someone_. All I'm saying is that _if_
you choose to go down this particular branch of the rabbit hole, it is
possible to learn the essentials more expeditiously than reading a 40 page
document.

> Designing your own CSPRNG doesn't help you

That depends on what kind of back door it is. If it's just /dev/urandom which
is compromised then rolling your own CSPRNG does help. And a backdoored
/dev/urandom is not a completely unreasonable threat model. It's a lot easier
to hide a backdoor in a CSPRNG than in just about any other part of the system
because the I/O behavior of a compromised CSPRNG can be indistinguishable from
a reliable one.

But yes, if you're approaching this level of paranoia then switching to an
open-source OS is probably more bang for the buck. But even there, are you
sure that the code for /dev/urandom has been properly audited?

~~~
tptacek
Yes.

~~~
lisper
Do I really need to explain why that's not a constructive answer?

~~~
tptacek
You asked a question I have a very straightforward answer for, and so I gave
it to you.

~~~
lisper
OK, but the way you interpreted my question was not the way I meant it. You
had already made it clear that you trust vendors. And that's fine. It's not
unreasonable to trust a vendor. You have to trust _someone_.

When I asked, "Are you sure..." I did not mean "you, Thomas Ptacek." I didn't
even mean, "You, Hanno Böck" even though he is the one I was actually
responding to. I meant, "You, some hypothetical person in a hypothetical
scenario", specifically, a scenario where you (the hypothetical person, not
you, Thomas Ptacek) are "approaching this level of paranoia", i.e. where
(hypothetical) you believe that a compromised CSPRNG is a possibility you need
to seriously consider for whatever reason. How can _that_ person be confident
that they can trust OpenBSD?

In case you are tempted to take another whack at an answer, let me stipulate
that I am assuming that this hypothetical person to whom the question is being
addressed is reasonably technically competent but not a crypto expert. In
particular, my hypothetical person does not know who Thomas Ptacek is, and so
has no reason to lend any particular credence to his assessment of the
situation in the absence of other evidence or arguments.

~~~
tptacek
You asked whether the LRNG had been competently audited. It has been, by
multiple groups.

If you'd asked me whether the XNU kernel RNG has been audited, I would give
the same answer. Different groups, of course.

I don't see how these answers depend on who asked the question. It could be me
asking, it could be Trevor Perrin asking, it could be Theodore T'so. The
scrutiny received by both of these CSPRNGs would be the same.

If you believe your personal machine has been so completely compromised that
the code for your kernel CSPRNG differs materially from the current reference
code that has been reviewed, you have bigger problems than your CSPRNG.
Whether you have those problems or not, writing an ad hoc userland CSPRNG is
unlikely to mitigate any problem, but is very likely to cause new ones.
Practically all major crypto randomness vulnerabilities are caused by userland
RNGs.

The funny thing about this thread is that I thought I'd entered it by agreeing
with you! Certainly, I think this RFC is pretty dumb.

~~~
lisper
> You asked whether the LRNG had been competently audited.

No, that's not what I asked. I asked _how can one know_ whether or not it has
been competently audited. Those are two very different questions. (An
illustrative analogy: "Does the Higgs boson exist?" and "How do we know that
the Higgs boson exists?" are two very different questions. The answer to the
first question is "yes". The answer to the second question is a very long
story.)

> It has been, by multiple groups.

Yes, I know. Again, that's not what I asked. What I asked was: how can someone
who doesn't know who you are, and hence is not willing to take your word for
it, convince themselves that this statement is true?

> I don't see how these answers depend on who asked the question.

Do you understand it now?

> I thought I'd entered it by agreeing with you!

And I'm pretty sure you still do :-)

~~~
tptacek
My suggestion is, if you're wondering whether the LRNG has been competently
audited, that you ask someone in a position to know. There are lots of those
people.

~~~
lisper
OK, but that only works for open-source OSs, not commercial ones. Also, it
really helps to have a certain amount of crypto-savvy to be able to
distinguish a competent consultant from a snake-oil salesman.

BTW, /dev/urandom on OS X may be random, but it is ridiculously slow:

``` time head -100000 /dev/urandom > /dev/null

real 0m1.832s user 0m0.015s sys 0m1.817s ```

So there's another reason someone might want to implement their own CSPRNG.

~~~
tptacek
I don't understand. For closed-source operating systems, why can't you do the
exact same thing? Just ask people who might know. You won't get specific
answers, because that kind of work happens under NDA, but you'll get the
answer you need, which is in this case "yes, they've been reviewed, by
experts". Take yes for an answer!

~~~
lisper
Once again I find myself feeling like I'm about to insult your intelligence by
explaining something that you surely already know: Computer security is
different from all other areas of software engineering because it is
inherently adversarial. One of the tactics that attackers use is to conceal
the fact that they are attackers (this is how social engineering attacks work,
for example). There can be no more ideal concealment for an attacker than to
be widely accepted as a trustworthy authority on computer security. Hence it
is unwise to assume that a person or entity is not acting on behalf of an
adversary simply because they appear to be a trustworthy authority.

You don't even have to get very far into tinfoil-hat territory to have
reasonable skepticism about the security claims of closed-source software. The
person you are consulting may well have a good-faith belief based on good
evidence that everything is hunky-dory. But the problem is that unless that
person has had access to every stage of the production process there is no way
that they can be sure that _they_ have not been dealing with an adversary
somewhere along the line. For example: it would not be difficult for someone
with the right skill and access within Apple to insert a back door that would
be undetectable even to other Apple employees. And it would not be beyond the
capabilities of state actors to identify such a person and coerce them to do
this. Again, I'm not saying this has happened, only that it's possible, and so
if the stakes are high enough for you, then you need to take such things into
account even if you ultimately end up deciding not to worry about them. But
given the low cost of educating yourself how to implement your own CSPRNG, the
extremely high value of the system CSPRNG as a target, and the ease with which
it could be compromised by someone with the right access, I think it is not at
all unreasonable to choose to roll your own even if there are experts out
there telling you that you don't need to.

------
jimhefferon
I know this isn't the point of the document but it is so strange that it has
hyperlinks (from the TOC to the pages) but the equations ans diagrams are in
ASCII art.

~~~
user5994461
Text version is here.
[https://tools.ietf.org/rfc/rfc4086.txt](https://tools.ietf.org/rfc/rfc4086.txt)

The IETF always published raw text with ASCI art.

Then there are nicer HTML and PDF, with links, table of contents and nice
formatting.

