At 20:27 9/23/2013 +0200, Richard Könning wrote: >/dev/random is a PRNG which blocks when the (crude) >entropy estimation of the entropy pool falls below a >limit. Besides this there are afaik no big >differences between /dev/random and /dev/urandom.
In the sense that all TRNG outputs are run through various algorithms that "mix" and "whiten" the data to assure uniform statistical distribution, all TRNGs could be called PRNGs. However the crucial difference is that TRNG post-filter output is irreproducible where a "pseudo random number generator" will predictably generate identical streams of output given the same seed. So Intel's RDRAND is a PRNG in the sense you seem to be invoking. I'll take the heavily reviewed open-source Linux algorithm over Intel's or anyone else's black-box. I believe Linus Torvalds is correct when he says that "they know what they are doing." /dev/urandom (in newer kernels) continually re-seeds itself from the common entropy pool but will apply TRNG when demand exceeds supply. My desire is to experiment with having 'openssl' rely on the better quality /dev/random source (enhanced by a higher-volume input such as from a TPM or RDRAND) at the cost of occasional millisecond time-scale delays. From random.c: >The two other interfaces are two character devices >/dev/random and /dev/urandom. /dev/random is >suitable for use when very high quality randomness >is desired (for example, for key generation or >one-time pads), as it will only return a maximum >of the number of bits of randomness (as estimated >by the random number generator) contained in the >entropy pool. > >The /dev/urandom device does not have this limit, >and will return as many bytes as are requested. >As more and more random bytes are requested >without giving time for the entropy pool to >recharge, this will result in random numbers that >are merely cryptographically strong. For many >applications, however, this is acceptable. If you can convince the kernel developers that the above statement is incorrect and have a patch accepted to modify the text, I'll abandon my exploration of employing /dev/random. Until then I find the random.c comments authoritative. I certainly can an will dig into the code. Merely posted here in the hope that someone was familiar with the behavior of 'openssl' in the face of blocked requests for random bytes. ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
