Dave Thompson
2017-10-30 22:21:33 UTC
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
gathered.
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
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
gathered.
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