

Why secure systems require random numbers - jgrahamc
http://blog.cloudflare.com/why-randomness-matters

======
tptacek
FWIW: I don't like OpenSSL as a CSPRNG; I think you'd generally better off
replacing it with direct reads from urandom.

Another useful thing to know: there is lately a push towards crypto
constructions that minimize dependencies on randomness. For example, there's
"deterministic" DSA that replaces the nonce with a uncorrelated (psuedorandom)
bits from digest functions. If you see people talking about cryptosystems
being bad or good based on CSPRNG dependencies, that's the idea they're
talking about.

This was a good post. For the record, we've been repeatedly trying and failing
to hire Daniel Franke ever since that HN hack.

~~~
yalogin
Extrapolating a little when you say you don't like openssl as a CSPRNG, do you
mean you don't like any of the CSPRNGs or just the openssl one? For e.g. NIST
specified some CSPRNGs in the DSA specification.

You don't like them because the application might end believing it has more
entropy than it really has or are there other reasons?

~~~
tptacek
I don't like the OpenSSL CSPRNG in particular for the same reasons 'rwg cited.
But more broadly, I don't like app-layer CPSRNGs. CSPRNGs are one thing that
benefits from being centralized on the OS.

------
zellyn
It's been linked often, but allow me to re-recommend the Matasano Crypto
Challenge for learning more. It has a section on pseudo-random number
generation. [http://tinyurl.com/mtsocrypt](http://tinyurl.com/mtsocrypt)

------
AceJohnny2
There are a bunch of cheap, well supported, hardware random number generators
out there. For example, the Entropy Key:
[http://www.entropykey.co.uk/](http://www.entropykey.co.uk/)

~~~
justincormack
"Please note that there is a very long waiting period for Entropy Keys at the
moment."

That notice has been there for a very long time, not sure what this period
is...

(maybe they have run out of randomness!)

------
cryptbe
Two reasons why crypto needs randomness:

1) You need to generate keys that nobody can guess.

2) Much of modern crypto is built based on probabilistic encryption [1].

[1]
[http://theory.lcs.mit.edu/~cis/pubs/shafi/1984-jcss.pdf](http://theory.lcs.mit.edu/~cis/pubs/shafi/1984-jcss.pdf)

------
moloch
Notably newer Intel CPUs (iirc, Sandybridge and later) include a true random
number generator, but I'm not sure how much software supports it yet.

~~~
TsiCClawOfLight
Which people fear is backdoored by the NSA.

~~~
lambda
No, people don't directly fear it's backdoored by the NSA. There has never
been any evidence that it's backdoored by the NSA. The algorithm it's
documented as using (based on AES) is not the one that was backdoored by the
NSA (Dual_EC_DRBG), though you would have to take a look at the chip with a
scanning electron microscope in order to verify this.

The kernel developers just don't think it's a good idea to blindly trust
unauditable hardware random number generators. Using it in conjunction with
other sources of entropy is one thing; just using it on its own is putting a
bit too much faith in it, especially because the code that uses it uses a
generic wrapper for any hardware random number generation instruction, so if
AMD or ARM or MIPS chips later come with random number generators, the kernel
will be able to take advantage of their entropy without putting itself at risk
if one of them is backdoored.

There's a difference between fearing that something is backdoored, and
thinking that it's not a good policy not to blindly trust something.

~~~
nimrody
Not sure if I'm reading the code correctly, but it seems like it mixes the
hardware random bits with the output of what would be generated otherwise.
I.e., Linux does not add the the RDRAND output to the entropy pool.

This means it might take more time to generate the required number of random
bits. So not trusting RDRAND means a process might block waiting for random
data.

Then again, hardware generators may be affected by external forces - other
than the NSA. For example, CPU temperature.

~~~
lambda
Yes, that's right, the kernel doesn't add it to the entropy pool. RDRAND is a
cryptographically secure pseudo-random number generator, it doesn't give you
direct access to the full entropy of the hardware random number generator
(that is planned with the RDSEED instruction, which isn't shipping yet[1]).
RDRAND re-seeds a CSPRNG periodically with its hardware RNG, but it's not
appropriate to feed directly in as the seed of another CSPRNG like Linux's
/dev/random. Intel does provide a suggestion for how to ensure that it gets
reseeded, so you can ensure you have seed-grade entropy in their software
implementation guide[2]; it involves either calling it 1022 times, or running
it 32 times with a 10 μs wait per iteration.

In Linux, there's a user-space deamon, rngd, that's responsible for mixing
hardware random number generator entropy into the entropy pool. That's a more
appropriate place to put the logic for adding entropy from RDRAND into the
entropy pool; you probably don't want to be doing those 1022 iterations or 32
iterations with a sleep in between in the kernel itself.

The kernel just uses it as a parallel CSPRNG along with its own built in one.
It runs its own, and RDRAND, and xors the results together. This allows it to
get fast, good random numbers (which are important early in the boot sequence,
for things like ASLR) even if its own entropy pool does not have very good
entropy yet. This makes its random number generation at least as good as the
stronger of RDRAND and the kernel's own CSPRNG. It does mean that if RDRAND
(or some other processor's similar instruction, once other processors add it;
it would be quite valuable on ARM and MIPS as embedded machines tend not to
have very good entropy sources) is backdoored, _and_ the kernel entropy pool
has insufficient entropy, it may be possible for someone with knowledge of the
backdoor to crack it, with a difficulty equal to the amount of entropy that
the Linux entropy pool has. However, this is only true if you are using the
non-blocking random number source, which tends to be used by things that need
fast random numbers but don't need particularly good seed-grade entropy, like
ASLR. If you need high-quality entropy, just use /dev/random and it will block
until you have enough entropy to satisfy your request.

[1]: [http://software.intel.com/en-us/blogs/2012/11/17/the-
differe...](http://software.intel.com/en-us/blogs/2012/11/17/the-difference-
between-rdrand-and-rdseed) [2]: [http://software.intel.com/en-
us/articles/intel-digital-rando...](http://software.intel.com/en-
us/articles/intel-digital-random-number-generator-drng-software-
implementation-guide)

------
grannyg00se
I feel there is some relevance to the images in the article that I don't
understand..

~~~
kristianp
Yes, that first disney image left me confused and slightly uncomfortable!
Hovering over it give an indication though, the tooltip says "so random!".

Of course the other images mostly make sense, but it would have been
informative to have captions on some of them, such as the the second image,
which has alt-text of "the three".

------
andrewcooke
who are the other two in the photo?
[http://blog.cloudflare.com/static/images/vonneumann.jpg](http://blog.cloudflare.com/static/images/vonneumann.jpg)

(von neumann is on the left, i think?)

~~~
jgrahamc
Feynman and Ulam.

I liked that photo because there's von Neumann who I referenced, Ulam because
of the Monte Carlo method
([https://en.wikipedia.org/wiki/Stanislaw_Ulam#Monte_Carlo_met...](https://en.wikipedia.org/wiki/Stanislaw_Ulam#Monte_Carlo_method))
and Feynman because, well, Feynman's cool.

------
philip1209
Why not use a quantum random number generator? It is truly random, and ones
based on photon path output bits.

------
mappu
<meta> I didn't expect such a bright topcolor!

