Forum Replies Created
-
First, TL;DR- use /dev/urandom. More info here: https://pthree.org/2014/07/21/the-linux-random-number-generator/
However, on most Linux distributions, random will block when no entropy is available (and it uses real entropy) and urandom will not, however, I don’t believe that urandom uses any real entropy what so ever, it is all pseudo random.
Not quite. First off, entropy isn’t something you use. Entropy is a measurement, not an object. You don’t “use entropy”, you “estimate entropy”. When you have an entropy estimate value, it’s giving you an approximation of how unpredictable something is, in this case, the state of the computer. As the computer works on algorithms, its state becomes more predictable. As such, the entropy estimate decreases. But it’s important to understand that you’re not “using entropy”. You’re putting your computer into a more predictable state, and the entropy estimate is decreasing.
Second, both /dev/random and /dev/urandom have entropy estimates. In fact, there are three “entropy pools” with the Linux CSPRNG. They are the “input pool entropy”, the “blocking pool entropy”, and the “non-blocking pool entropy”. The input pool value is what is read at /pool/sys/kernel/random/entropy_avail, and has a maximum value of 4096 bits. The other two pool values are not available via userspace tools, and have a maximum value of 1024 bits.
Thirdly, both /dev/random and /dev/urandom use the exact same cryptographically secure pseudorandom number generator (CSPRNG). The only difference, is when the input pool entropy estimate is decreased to 0, the blocking pool will stop producing numbers from the CSPRNG, whereas the /dev/urandom device will not.
What’s important to understand here, though, is BOTH /dev/random and /dev/urandom use a single shared CSPRNG. Further, the output from /dev/urandom is indistinguishable from true random data. It is no less insecure than /dev/random., and /dev/random is no more secure than /dev/urandom. The only thing that can be said about /dev/random is that performs worse than /dev/urandom for outputting pseudorandom numbers for the Linux kernel CSPRNG.
If you feed a TRNG into the input pool for the CSPRNG, you will only prevent /dev/random from not blocking. However, the CSPRNG mixes data using the SHA-1 cryptographic hash function. So, data coming out of /dev/random and /dev/urandom is nothing more than SHA-1 mixing of the input pool, which includes the TRNG. So even if you add the TrueRNG to the Linux kernel CSPRNG, the output ends up being pseudorandom anyway.
Finally, most mature cryptographic software uses the non-blocking pool to get its random numbers. This includes OpenSSL and libssl, OpenSSH, Kerberos, and OpenVPN. GnuPG relies on /dev/random to ensure that the state of the computer is kept in an unpredictable state, while getting random numbers to generate an assymmetric key pair. This doesn’t mean that the keys generated by GnuPG are any more “secure” than those generated using /dev/urandom. Some immature cryptographic software relies on /dev/random for its random number source, such as apg(1). All this does is piss off users, due to poor performance, and it doesn’t provide any more secure output than what in supplied by /dev/urandom.
So, I found something interesting. When reading the devices directly, I get 47 KBps per device. When adding both of them to the entropy pool, combined, I see 18 KBps. I know that the Linux CSPRNG does a SHA1(SHA1(SHA1(unsigned_int))) from the input entropy pool, but I wouldn’t expect it to be that drastic. Combined, I should see about 95 KBps. Instead, I’m seeing 18 KBps. One-fifth of the natural throughput. I’m not blaming anyone, just really, really interesting.
Proof:
$ dd if=/dev/ttyACM0 of=/dev/null bs=1024 iflag=fullblock & [1] 24546 $ kill -10 24546 203+0 records in 203+0 records out 207872 bytes (208 kB) copied, 4.4209 s, 47.0 kB/s $ kill 24546 [1] + terminated dd if=/dev/ttyACM0 of=/dev/null bs=1024 iflag=fullblock $ dd if=/dev/ttyACM1 of=/dev/null bs=1024 iflag=fullblock & [1] 24622 $ kill -10 24622 205+0 records in 205+0 records out 209920 bytes (210 kB) copied, 4.46186 s, 47.0 kB/s $ kill 24622 [1] + terminated dd if=/dev/ttyACM1 of=/dev/null bs=1024 iflag=fullblock $ sudo rngd -r /dev/ttyACM0 -p /var/run/rng-acm0.pid $ sudo rngd -r /dev/ttyACM1 -p /var/run/rng-acm1.pid $ dd if=/dev/random of=/dev/null bs=1024 iflag=fullblock & [1] 24942 $ kill -10 24942 53+0 records in 53+0 records out 54272 bytes (54 kB) copied, 3.02073 s, 18.0 kB/sThat’s surprising.
-
This reply was modified 9 years, 9 months ago by
atoponce.
-
This reply was modified 9 years, 9 months ago by
