Dave- Thanks for the explanation. I wasn’t at the summit, so am likely missing some context.
Doesn’t ATS rely on openssl to manage random number generation? —Eric On Oct 30, 2017, at 6:21 PM, Dave Thompson <[email protected]<mailto:[email protected]>> wrote: 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
