
Myths about /dev/urandom (2014) - Ivoah
http://www.2uo.de/myths-about-urandom/
======
technion
I've given up on the hope that these myths will ever die. Every time it's
relevant, someone pipes up complaining urandom isn't safe for use, or will run
out of entropy. Have a look at the bugs for Node, Ruby and Wordpress.

And inevitably, the appeal to authority ends up referring to these projects.

Serious question, if I submitted a patch for the man page detailing the
content of this myths page, is there a chance it might go somewhere and put
somewhat of an end to some of this?

~~~
mkj
They got fixed last month.

[http://man7.org/linux/man-
pages/man7/random.7.html](http://man7.org/linux/man-pages/man7/random.7.html)

[http://man7.org/linux/man-
pages/man4/random.4.html](http://man7.org/linux/man-pages/man4/random.4.html)

[https://bugzilla.kernel.org/show_bug.cgi?id=71211](https://bugzilla.kernel.org/show_bug.cgi?id=71211)

~~~
marcosdumay
Finally!

It would be even better if there was some special file with the same semantics
of getrandom, so the advise could be simply "use this file, or the getrandom
syscal, whatever is easier". The way it is now, no special file is foolproof.

------
schoen
A useful article, originally from 2014 but updated recently.

Previous HN discussions:

[https://news.ycombinator.com/item?id=7359992](https://news.ycombinator.com/item?id=7359992)

[https://news.ycombinator.com/item?id=10149019](https://news.ycombinator.com/item?id=10149019)

~~~
djsumdog
I remember seeing it before. It's a good post.

What I think is really interesting is the question: how do you prove something
is random. If you take a chunk of data that uses strong encryption, without
headers or other identifiers, it should look like it has a random
distribution.

That's one of the reasons for the great concern around the Snowden leaks that
implied some manufactures had compromised their hardware AES chips:

[https://theintercept.com/2016/01/04/a-redaction-re-
visited-n...](https://theintercept.com/2016/01/04/a-redaction-re-visited-nsa-
targeted-the-two-leading-encryption-chips/)

------
Paul-ish
While it may be generally better to use /dev/urandom, what about the Mining
Your Ps and Qs paper?[1]. It finds that:

> Every software package we examined relies on /dev/urandom to generate
> cryptographic keys; however, we find that Linux’s random number generator
> (RNG) can exhibit a boot-time entropy hole that causes urandom to produce
> deterministic output under conditions likely to occur in headless and
> embedded devices. In experiments with OpenSSL and Dropbear SSH, we show how
> repeated output from the system RNG can lead not only to repeated long-term
> keys but also to factorable RSA keys and repeated DSA ephemeral keys due to
> the behavior of application-specific entropy pools.

This is mentioned a little at the end of the article. Would it be a breaking
change for Linux to block urandom at startup?

[1]
[https://factorable.net/weakkeys12.conference.pdf](https://factorable.net/weakkeys12.conference.pdf)

~~~
zeveb
Read 32 bytes (i.e., 256 bits) from /dev/random, write them to /dev/urandom,
and then use /dev/urandom for everything.

And every few months, send an email to Ted T'so with a patch fixing this
behaviour. Maybe if every single Linux user bugs him he'll finally capitulate.

~~~
virtualdxs
1\. That was exactly what I was thinking would work best as a workaround if
your program might run at boot-time.

2\. Perhaps somebody could create one of those preloaded email forms like
those political organizations do where you fill in your name and email and it
does the rest up to and including sending the email?

------
Buge
/dev/urandom does have a problem with not enough entropy sometimes. Yes it
never "runs out" of entropy when it has enough previously. But when a computer
first boots up, sometimes it doesn't have enough entropy yet, and gives bad
output.

This causes problems in practice, allowing people to crack RSA private keys.
[https://factorable.net/weakkeys12.extended.pdf](https://factorable.net/weakkeys12.extended.pdf)

~~~
masklinn
Yes in that case you want to use getrandom/getentropy.

Also note (as TFA indicates) that urandom not blocking on uninitialised
entropy pool is mostly a Linux thing e.g. BSD urandom _will_ block until the
system the system is correctly initialised.

~~~
tveita
"that case" is _every_ case unless you know and control exactly which OS, on
which (potentially virtual) hardware and under which circumstances your code
is going to run, now and in the future.

That excludes anything that is meant to be used by other people. Fragile
security is no security, and relying on undocumented assumptions like "is not
running on Linux", "starts late in the boot process" and "is not running on an
VM" is incredibly fragile.

Unfortunately people who really should know better keep writing articles like
this one, dispelling the "myth" that urandom works exactly as documented.

Which leads us to situations like this:

    
    
      $ dmesg|grep random
      [    0.469142] random: systemd-tmpfile: uninitialized urandom read (16 bytes read, 3 bits of entropy available)
      [    0.470297] random: systemd-udevd: uninitialized urandom read (16 bytes read, 3 bits of entropy available)
      [    0.470325] random: systemd-udevd: uninitialized urandom read (16 bytes read, 3 bits of entropy available)
      [    0.470877] random: udevadm: uninitialized urandom read (16 bytes read, 3 bits of entropy available)
      [    0.470890] random: udevadm: uninitialized urandom read (16 bytes read, 3 bits of entropy available)
      [    0.471936] random: systemd-udevd: uninitialized urandom read (16 bytes read, 3 bits of entropy available)
      [    0.471950] random: systemd-udevd: uninitialized urandom read (16 bytes read, 3 bits of entropy available)
      [    0.471969] random: systemd-udevd: uninitialized urandom read (16 bytes read, 3 bits of entropy available)
      [    0.472132] random: systemd-udevd: uninitialized urandom read (16 bytes read, 3 bits of entropy available)
      [    0.472142] random: systemd-udevd: uninitialized urandom read (16 bytes read, 3 bits of entropy available)
      [    1.909082] random: nonblocking pool is initialized
    

Oops, hope none of that was for anything important, say generating a long-term
cryptographic key! But of course if we're to believe TFA... "Fact:
/dev/urandom is the preferred source of cryptographic randomness on UNIX-like
systems."

Just use getrandom. If you can, consider using _only_ getrandom. But if your
code must work on systems without getrandom or similar, before following the
advice of this article, ask yourself if what you are doing is worse of
blocking, or reading out a grand total 3 bits of entropy. You'd probably
prefer the former.

~~~
JdeBP
"I don't think systemd is doing anything wrong here, and we really shouldn't
change anything." \-- Lennart Poettering, 2016-09-18,
[https://github.com/systemd/systemd/issues/4167#issuecomment-...](https://github.com/systemd/systemd/issues/4167#issuecomment-247835419)

The bug report also explains what systemd is doing here.

"systemd starts allocating those hashtables very very early on, before any
process is forked off... It's par tof the initialization scheme of systemd
really. Hence there's basically nothing else going on in the system, execept
what is done by the kernel itself", -- Lennart Poettering, 2016-05-05,
[https://lists.freedesktop.org/archives/systemd-
devel/2014-Ma...](https://lists.freedesktop.org/archives/systemd-
devel/2014-May/019037.html)

"moving that blocking behavior to /dev/urandom simply does not work. The
system does not boot. The reason to this issue is actually quite simple. The
init process of systemd reads /dev/urandom for whatever purpose. Now, when
/dev/urandom blocks during boot, systemd will be blocked too." \-- Stephan
Mueller, 2016-10-22,
[https://lkml.org/lkml/2016/10/21/982](https://lkml.org/lkml/2016/10/21/982)

------
kbaker
tldr; just use /dev/urandom --- this should be at the top of the page.

Maybe prefix the bold sections with Myth: so it is easier to read. I was
really confused as to which side of the argument the author was on at first...

~~~
citrin_ru
Or better use getentropy(2)/getrandom(2) when it is possible.

~~~
JoshTriplett
True, but never pass GRND_RANDOM or GRND_NONBLOCK.

~~~
Gaelan
NONBLOCK just returns an error code instead of blocking. No harm in that,
AFIAK.

~~~
marcosdumay
Just wait until people start using the EAGAIN value in keys.

------
alpb
Also Filippo Varsaldo has a nice talk about this:

[https://www.youtube.com/watch?v=Q8JAlZ-
HJQI](https://www.youtube.com/watch?v=Q8JAlZ-HJQI)

~~~
Foxboron
Please don't link to talks from CCCen. They contain adds and is not the
offical channel from the C3VOC. Link to the mediacccde channel
([https://www.youtube.com/user/mediacccde](https://www.youtube.com/user/mediacccde))
or better; [https://media.ccc.de](https://media.ccc.de).

[https://media.ccc.de/v/32c3-7441-the_plain_simple_reality_of...](https://media.ccc.de/v/32c3-7441-the_plain_simple_reality_of_entropy)

~~~
Encounter
Huh, they do a good job of making it look official. (Definitely more so than
mediacccde.)

I'll have to link from media.ccc.de from now on.

------
ComodoHacker
So what are the cases when you should _actually_ use /dev/random and not
/dev/urandom? The article fails to address this in clear.

~~~
teamhappy
You shouldn't use /dev/random. The article makes that very clear.

~~~
ComodoHacker
/dev/random still exists for a reason, and I believe the reason isn't backward
compatibility only.

~~~
teamhappy
" _The /dev/random interface is considered a legacy interface_, and
/dev/urandom is preferred and sufficient in all use cases, with the exception
of applications which require randomness during early boot time; ..."

From [http://man7.org/linux/man-
pages/man4/urandom.4.html](http://man7.org/linux/man-
pages/man4/urandom.4.html)

~~~
ComodoHacker
OK, "applications which require randomness during early boot time" is one such
case. Thank you for pointing out.

~~~
tptacek
No, it isn't. During early boot time, you should use the system call
interface, not the special files.

------
haarts
I am so confused about this all the time. My solution is to go see what Go is
using:
[https://golang.org/src/crypto/rand/rand.go](https://golang.org/src/crypto/rand/rand.go)
Trusting them to do the Right Thing.

Is there a good reason why /dev/random AND /dev/urandom exist?

~~~
lmm
What do you want the behaviour to be when there isn't enough entropy to
provide high-quality random numbers? For cases where you need the random
number right now, you probably just want the best-quality number available
(urandom). For cases where it's an important random number you'll be using for
a long time, like SSH/SSL key generation, you probably want to block until
more entropy is available (random).

~~~
tptacek
There's no such thing as a "low quality random number" from a CSPRNG. The
outputs of a CSPRNG are either insecure, because the CSPRNG hasn't been seeded
properly, or they're secure --- for all intents and purposes, forever. That's
the problem with the old version of the Linux man page.

The new version of the man page resolves this problem, and says outright that
urandom is the preferred interface, and that /dev/random is obsolete;
applications that run during early boot time should instead use the system
call interface.

~~~
lmm
> The outputs of a CSPRNG are either insecure, because the CSPRNG hasn't been
> seeded properly

In what sense is this not a "low quality random number"? Every CSPRNG I've
seen will output numbers that pass many statistical tests for randomness even
if seeded with e.g. zero - is that not a "low quality random number" in the
usual sense of those words?

~~~
JdeBP
What they are getting at is that thinking of this in terms of the "quality of
the randomness" is thinking about it in quite the wrong way that leads one
right up the garden path; so stop even thinking about it like that. Discard
that mental model.

The randomness has the _same_ quality. It's the same pseudo-random number
generation algorithm. Only in one case, the world knows your seed value, and
can predict anything that you do that derives from pseudo-randomness; whereas
in the other case, the world does not know your seed value, should your seed
value be discovered somehow you are regularly re-seeding anyway, and the world
cannot predict your actions.

------
jlgaddis
I bought a TrueRNG v3 [0] a month or so ago and have been using it with rngd /
rng-tools.

I wish rngd was easier to use with multiple entropy sources, however. Even w/
RDRAND (times two -- dual CPUs), a TPM, and the TrueRNG, it's difficult to
(easily) tell which of these are being used and/or if more than one is being
used.

Ideally, I'd like to be able to tell rngd to use/mix the TrueRNG, RDRAND in
both CPUs, the TPM, and any other entropy sources I may come up with, such as
RTL-SDRs doing funky things [1]. I suppose I could just run multiple instances
of rngd, though.

Anyway, I've switched to just using /dev/random for pretty much everything
(where it can be configured) since, with the TrueRNG, it never blocks on me
now.

[0]: [http://ubld.it/truerng_v3](http://ubld.it/truerng_v3)

[1]: [https://www.google.com/search?q=rtl-
str+entropy](https://www.google.com/search?q=rtl-str+entropy)

~~~
tptacek
Why would you do this? What problem is a USB hardware RNG solving for you?

~~~
jlgaddis
In this particular case, I'm evaluating it on my workstation. The intended
use, however, is for an offline, headless machine (that is normally powered
off) that is used to generate cryptographic keys.

Do I absolutely _require_ it? Probably not. For $50, though, I thought "might
as well try it".

~~~
tptacek
I would recommend you not do this.

------
wruza
What I've got from this thread is that you never touch security-related prngs
unless you're an expert in security, cryptography and operating systems, _all
at the same time_ , and even then you care a lot. Thanks for deeper debunking.

------
CiPHPerCoder
The advice on this page is accurate and in line with what cryptography experts
will recommend.

That said, if you're looking for more of the _how_ and less of the _why_ :
[https://paragonie.com/blog/2016/05/how-generate-secure-
rando...](https://paragonie.com/blog/2016/05/how-generate-secure-random-
numbers-in-various-programming-languages)

Contains snippets and recommendations for C/C++, Erlang, Go, Java, (Browser)
JavaScript, .NET, Node.js, PHP, Python, Ruby, and Rust.

~~~
Dylan16807
Though you're answering a different (more relevant, but different) "how".
That's "how do I find a library for random numbers". The article is focused on
getting random numbers directly from the Linux kernel, and the "how" there is
invoking getrandom(buffer, len, 0).

------
matt_wulfeck
This is really no problem now that Intel chips ship with RDRAND instructions.
Linux should follow BSD/Mac's footsteps and incorporate a good CSPRNG non-
blocking devices (after seed). I believe BSD is moving towards Fortuna, which
is perfect for this use-case.

With these instructions you'll always get a "good"[1] seed for your CSPRNG,
and that includes virtual machines and clones.

[1] Of course that depends on how much you trust Intel. Don't ask the crypto
mailing lists whether this is a good idea :-)

~~~
hug
From Theodore Ts'o, 2012:

"Create a new function, get_random_bytes_arch() which will use the
architecture-specific hardware random number generator if it is present.
Change get_random_bytes() to not use the HW RNG, even if it is avaiable.

...

So it's much better to use the HW RNG to improve the existing random number
generator, by mixing in any entropy returned by the HW RNG into /dev/random's
entropy pool, but to always _use_ /dev/random's entropy pool."

[http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.g...](http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=c2557a303ab6712bb6e09447df828c557c710ac9)

~~~
matt_wulfeck
I'm not sure I'd say it's better or worse. I think it's unnecessary. You only
need like ~16 bytes of a random seed and your CSPRNG will run forever with
unlimited unpredictable stream of bits.

Intels instructions perform the same as a HWRNG only it's built in to every
chipset >= Ivy bridge. I actually think Linux's rng-tools incorporates it as a
mix automatically.

------
bluedino
One to add - it's not fast at providing a value

I remember learning this when I found /dev/urandom multiple times slower than
/dev/null while writing garbage data to disk.

~~~
paulddraper
Oh really :)

------
anon335dtzbvc
its like aes 128 bit vs aes 256 bit, both are secure but when in doubt me, you
and the nsa choose 256 bit

------
joelbondurant
"And even if you need that peace of mind, let me tell you a secret: no
practical attacks on AES, SHA-3 or other solid ciphers and hashes are known in
the “unclassified” literature, either. Are you going to stop using those, as
well? Of course not!"

[http://www.pcworld.com/article/3117728/security/why-
quantum-...](http://www.pcworld.com/article/3117728/security/why-quantum-
computing-has-the-cybersecurity-world-white-knuckled.html)

[https://en.wikipedia.org/wiki/Grover's_algorithm](https://en.wikipedia.org/wiki/Grover's_algorithm)

~~~
Tomte
"Practical attacks". "Quantum computers".

I fail to see how these might be related.

~~~
joelbondurant
If you're working on storing cat videos on your personal website, I completely
agree.

~~~
Tomte
No, I'm storing urandom articles on my personal website.

Cat videos are much too popular and a lot bigger, and since I'm paying for
traffic... [0] ;-)

[0] regular traffic: ~30 MB/day, today (projected): ~3.5 GB

