trafficserver-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dave Thompson <>
Subject Secure usage of /dev/random vs /dev/urandom
Date Mon, 30 Oct 2017 22:21:33 GMT
At the ATS summit last week, there was some confusion regarding appropriate
use of /dev/random vs /dev/urandom .  Depending on the usage, exploits
associated with getting this wrong can be severe.  I'll sleep better, not
letting this drop before attempting to explain which is an appropriate
source. ;-)

>From a linux perspective, the difference between these two sources of
random data is that one is an entropy tracking source (/dev/random) which
will block reads while the entropy pool is low, versus /dev/urandom which
will always return a timely response regardless of the state of the entropy
pool. When random numbers come from a deterministic pseudo-random number
generator algorithm, the only real thing that is actually random is that
which is collected in the entropy pool.

The linux entropy tracked source does come at a cost.   I have measured
upwards of 2 seconds per byte.  Depending on the application, one might be
waiting ~2 minutes to get keying material, which often imposes design
constraints.  Naturally, if one doesn't need high quality random, don't use
an low entropy blocking source.    /dev/urandom returns requested material
almost immediately.  For purposes of TLS session-ticket-encryption-key
generation (which is the context the question came up), one *absolutely*
must know their PRNG is properly seeded.  A 128-bit cipher operating at
128-bit cipher strength requires a key that had 2^128 different
possibilities.  If one doesn't pay attention to the entropy level seeding
their PRNG, one has no idea.

Check the OS that the code is running on.  On linux a 'man 4 random', is
quite explicit in that long-lived GPG/SSL/SSH keys should *not* use
/dev/urandom. Different OS may have different constraints.


Further excerpts from the linux 'man 4 random':

"When read, the /dev/random device will only return  random  bytes  within
the  estimated  number of bits of noise in the entropy pool.  /dev/random
should be suitable for uses that need very high quality  randomness  such
as one-time pad or key generation.  When the entropy pool is empty, reads
from /dev/random will block until additional environmental noise is

A  read  from  the  /dev/urandom  device  will not block waiting for more
entropy.  As a result, if there is not sufficient entropy in the  entropy
pool, the returned values are theoretically vulnerable to a cryptographic
attack on the algorithms used by the driver.  Knowledge of how to do this
is not available in the current non-classified literature, but it is
theoretically possible that such an attack may exist.  If this is a  concern
in your application, use /dev/random instead."


Dave Thompson

View raw message