
/dev/random – a new approach - Tomte
http://lwn.net/Articles/684568/
======
tptacek
This proposed design comprehensively ratifies Linux's nonsensical legacy
random/urandom division; for instance, it maintains a "512 bit emergency
entropy level" in case urandom becomes "stressed". It appears to be motivated
principally by concerns about the quality of entropy being fed continually
into the LRNG --- which is a nonproblem.

This is silly.

There are three problems a kernel CSPRNG needs to address:

1\. It needs to seed itself reliably and not provide output when it's not
securely seeded.

2\. It needs to re-key itself regularly to provide forward secrecy and
recovery from attacks.

3\. It needs to be performant enough to be used in applications to the
exclusion of all other RNGs.

That's it. Once problem (1) is addressed, there is never again for the uptime
of the system a concern about the quality or "level" of entropy in the LRNG.
DRBGs like this document proposes are effectively stream ciphers (in fact:
Salsa20, the new hotness in bulk cipher designs, is essentially a hash DRBG
--- and, in the BSDs, a [crappy] stream cipher _was_ the RNG). "Entropy" keys
the cipher. The idea that you can "run low" on entropy is the same as the idea
that you can "run low" on key. No.

Kernel CSPRNGs do need continually updated entropy pools. But not because
their original entropy is depleted! Rather: you want your RNG to be updated so
that its "key" changes regularly, so that if your system is compromised
transiently, you'll recover.

And, of course, the division between /dev/random and /dev/urandom sabotages
goal (3) --- arguably the most important goal. Almost every time you've read
about some crypto randomness catastrophe --- from Debian commenting out their
RNG and reducing SSH key space to 16 bits, to Bitcoin wallets coughing up
private keys by repeating nonces --- you've been reading about _userspace RNG
failures_. People use userspace RNGs because they think the kernel RNG is too
slow. And they think the kernel RNG is too slow because they use /dev/random,
which obstinately refuses to provide output when --- wait, I'm not dignifying
/dev/random: it refuses to provide output _at random_.

~~~
aidenn0
Has anybody made a set of patches to give linux the BSD behavior (block until
seeded, then never block again)? I run into issues with /dev/random regularly
and while I can patch every single application, that feels like playing whack-
a-mole compared to patching the kernel.

~~~
nshepperd
If you're using udev, you can configure it to make /dev/random a symlink to
/dev/urandom (eg. [1]). Sadly that doesn't give you the "block until seeded"
behaviour though, and I don't know of any kernel patch doing that yet.

1\. [http://superuser.com/questions/309840/how-can-i-point-dev-
ra...](http://superuser.com/questions/309840/how-can-i-point-dev-random-to-
dev-urandom)

~~~
Natanael_L
You could make a script that prevents /dev/urandom from being made available
until /r/random stops blocking, to then also simultaneously create that
symlink.

Edit: on boot, first prevent access to /dev/urandom, then symlink it to
/dev/random. Then as soon as /dev/random stops blocking, reverse the direction
of the symlink. Same improved security, much simpler to use.

------
nullc
Gah. Another brain-damaged system that implements complex (and, no doubt,
broken) "entropy estimation" with a goal of delivering "information theoretic"
security that doesn't even have a structure where information theoretic
security could actually be proven.

To the extent that any applications exist where a information theoretic RNG
was required, this scheme does not provide one. Instead, it continues the to
offer an interface that causes confusion and insecurity without an apparent
benefit.

~~~
apeace
Has anyone offered a better patch? I'm genuinely curious and don't know.

~~~
tptacek
What's "a better patch"? We need to have a shared understanding of the problem
before we can evaluate solutions.

~~~
jwilkins
Unpredictable and unbiased source of bytes, even on server machines and
virtualized hardware at boot time.

------
Tomte
If I read this correctly, this new suggestion also keeps the entropy
estimation voodoo:

"By using the primary DRBG to serve /dev/random, the LRNG ensures that each
random number generated by the primary DRBG must be backed by an equal amount
of entropy that seeded the DRBG. Hence, the data derived from /dev/random is
backed by information theoretical entropy."

(page 21 of the PDF documentation)

~~~
twic
For an explanation of the voodoo nature of the blocking /dev/random, see:

[http://www.2uo.de/myths-about-urandom/](http://www.2uo.de/myths-about-
urandom/)

EDIT: or read tptacek's root comment on this very page.

~~~
sunnyps
Thanks! This article was very helpful.

------
nshepperd
So, more half-assed entropy estimation voodoo neither verified nor endorsed by
actual cryptographers?

For goodness' sake, Fortuna already exists. What happened to "don't invent
your own cryptography"?

~~~
acqq
If I understood it, this change is supposed to be fully compatible with the
existing interfaces and assumptions, it just claims to give more bits faster,
using Fortuna would mean more changes at once and would mean the client code
would have to change. Which is easier for OpenBSD to do than it is for Linux.

~~~
tptacek
Replacing the LRNG with Yarrow or Fortuna or something like it would not break
any client code, because no sane client code can rely on when /dev/random
decides to block --- even by the LRNG's broken definition, that blocking
happens at random, and could be deferred indefinitely if enough "entropy" were
available.

------
rwmj
Also, should we use /dev/urandom (on the host) to seed the CSPRNG in virtual
machines? [https://lists.gnu.org/archive/html/qemu-
devel/2016-04/thread...](https://lists.gnu.org/archive/html/qemu-
devel/2016-04/threads.html#02486)

~~~
strcat
The getrandom() call should be used if it's available, and /dev/urandom on
legacy systems. The system call blocks once when the system starts until the
RNG is initialized with enough entropy, and then never again.

------
ryuuchin
So this makes /dev/urandom more like Window's CryptGenRandom (aka
RtlGenRandom) which is using AES256 running in CTR mode as a DRNG.

I'm curious why there still needs to be a distinct /dev/random though. Hasn't
history shown that they should really just both point to the same thing? Is
there really a need for the difference here? Ditto with the entropy
estimation, why is this still a thing?

------
mikepurvis
The linked PDF:
[http://www.chronox.de/lrng/doc/lrng.pdf](http://www.chronox.de/lrng/doc/lrng.pdf)

Page 4: "The new approach implements the modeling of a slow noise source
within the LRNG based on the timing of interrupts and allowing other, even
fast operating noise sources to contribute entropy. As discussed above for the
legacy /dev/random, only the high-resolution time stamps deliver entropy for
hardware events and other information processed by the legacy /dev/random
implementation hardly have any entropy. This identification is used as a basis
that solely the timing of interrupts is used."

~~~
acqq
"The cryptographic processing of the entropic data is implemented with a well-
known and well-studied deterministic random number generator: an SP800-90A
DRBG as defined in [2] – naturally excluding the NSA-sponsored Dual-EC DRBG."

"The concept of the LRNG allows the selection of the used DRBG and the backend
cipher implementations at compile time."

Is SP800-90A DRBG really state of the art?

According to Wikipedia "the publication contains the specification for four
cryptographically secure pseudorandom number generators for use in
cryptography." Without Dual-EC it's still three different DRBGs. How good are
they? Is there anything better?

~~~
tptacek
They're fine. They're sane, straightforward, relatively simple constructions
based on hashes, HMAC, and ciphers running in CTR mode. You could make a
CSPRNG more complicated, but there's not much reason to.

The stuff that extends the "state of the art" beyond SP800-90A tends to be
system-specific and feature-based. For instance, the "estimators" in the LRNG
are an extension to SP800-90A (and a bad idea). Rolling over seed files are
another extension.

~~~
acqq
> They're fine

Thanks. Does it matter which one of the three is then selected? Only one can
be a default.

~~~
tptacek
Meh. Throw a dart.

------
matt_wulfeck
I didn't RTFA, but I'm wondering why Fortuna[1] hasn't seen better adoption or
excitement. I think the BSD team made the right approach of making
/dev/random|urandom both a CSPRNG, which if seeded and mixed is an unlimited
source of high quality entropy.

Fortuna also has the benefit of mitigating damage from a compromised
generator. If the generator is compromised it's very difficult to rewind the
RNG output and perform a history attack (is that even the right word for such
a thing?).

[1]
[https://www.schneier.com/cryptography/fortuna/](https://www.schneier.com/cryptography/fortuna/)

~~~
tptacek
Every kernel CSPRNG that continually collects entropy is effectively
mitigating damage from a compromised generator. This isn't something specific
to Fortuna.

------
Cyph0n
The Linux kernel is not using the true RNG circuitry included with all modern
microprocessors (this is not entirely correct - see /u/matt_wulfeck's
comment). As far as I know, this is because the kernel devs fear that the RNG
circuit can be backdoored, allowing an unwanted entity to control the output
of the random bitstream.

This is an issue I've been thinking about quite a bit. Is there a way to
somehow sign a circuit design on silicon and allow devs to check the circuit's
integrity?

For example, in the case of a TRNG, the developer can add a "verify"
instruction to ensure that the TRNG on the user's CPU is not compromised
before executing the RAND instruction. Of course, that's what the dev does,
but the signing itself is much more complex.

I've been looking through the literature and I haven't found much to go on. I
know it's likely impossible to do given how many layers there are between
silicon and machine code, but I'd like to at least give it a try.

~~~
lvs
A malicious module would only need to act like VW's defeat device to overcome
that check. When it senses some integrity/signing routine, it simply isolates
itself from a verifiable circuit.

~~~
Someone
For VW, that was easy because the test setup was known and very rigid.

If you randomly check, say, power usage and latency of the on-board RNG
(ideally combined with high-resolution IR recordings of the CPU), it will, at
least, be harder for the CPU manufacturer to install a backdoored RNG that is
active most of the time (but one that only gets activated after receiving some
trigger, say a specific instruction sequence would still be virtually
undetectable)

~~~
Nrsolis
The problem you are trying to solve is much closer to the "decidability
problem" than you might suppose at first sight.

------
jwilkins
/dev/urandom while entropy available is low:

    
    
      $ rngtest -c 200000 -b 2000 < /dev/urandom  
      .....
    
      rngtest: bits received from input: 4000000032
      rngtest: FIPS 140-2 successes: 199848
      rngtest: FIPS 140-2 failures: 152
      rngtest: FIPS 140-2(2001-10-10) Monobit: 24
      rngtest: FIPS 140-2(2001-10-10) Poker: 15 
      rngtest: FIPS 140-2(2001-10-10) Runs: 60
      rngtest: FIPS 140-2(2001-10-10) Long run: 54
      rngtest: FIPS 140-2(2001-10-10) Continuous run: 0
      rngtest: input channel speed: (min=3.782; avg=63.752; max=82.928)Mibits/s
      rngtest: FIPS tests speed: (min=4.559; avg=158.909; max=194.627)Mibits/s
      rngtest: Program run time: 83882495 microseconds
    

It gets much worse.

------
matt_wulfeck
Can someone help me understand why intel has both the rdrand and rdseed
instruction set? If your device outputs high quality random data, why would it
need two outlets?

~~~
JoshTriplett
[https://software.intel.com/en-us/blogs/2012/11/17/the-
differ...](https://software.intel.com/en-us/blogs/2012/11/17/the-difference-
between-rdrand-and-rdseed)

rdseed directly gives you the output of a hardware RNG, limited by the rate
that hardware RNG produces random bits. rdrand gives you CSPRNG output seeded
by rdseed.

------
ape4
If a machine is land locked without good sources of entropy, maybe it can go
out to the internet for some nice randomness.

~~~
twic
Perhaps some lovely clean Irish randomness:

[https://www.random.org/](https://www.random.org/)

Sadly, LavaRand, the connoisseur's choice of internet randomness, is no longer
with us:

[http://web.archive.org/web/20010926221159/http://lavarand.sg...](http://web.archive.org/web/20010926221159/http://lavarand.sgi.com/)

~~~
cpeterso
If the machine truly has little entropy to start, it might have trouble
establishing a secure TLS connection to the remote source.

That said, here is my little "wwwrand" script, that assumes Google News will
return unpredictable and unrepeatable content. You could also throttle curl
using --limit-rate to generate more interrupts for strace to log.

nice -n 19 strace -CTiv -ttt curl -LNv
[https://news.google.com](https://news.google.com) 2>&1 | shasum -a 512

~~~
twic
Surely if you want unpredictable and unrepeatable content, 4chan is the place
to go?

~~~
cyphar
/r9k/ can hook you up.

------
hsivonen
Is there a good reason not to copy what OpenBSD does in this area?

~~~
brohee
NIH

