[Cryptography] TRNG related review: rngd and /dev/random

Bill Frantz frantz at pwpconsult.com
Wed Jan 20 21:44:01 EST 2016


On 1/20/16 at 1:05 PM, tytso at mit.edu (Theodore Ts'o) wrote:

>On Wed, Jan 20, 2016 at 08:09:03AM -0800, Bill Cox wrote:
>>
>>I may be wrong about this, but the threat-case where I think this matters
>>is when an attacker gets access to the machine, learns the state of the
>>entropy pool, and then loses access.  Can the machine recover?
>>
>>If only 1 random bit per second is fed into /dev/random, but keys and IVs
>>are extracted from /dev/urandom at a bit-rate far higher than this, and if
>>the attacker remains as an eavesdropper on the network and can see the
>>results of every read to /dev/urandom, then the attacker needs only to make
>>a few guesses per second to keep the attacker's copy of the entropy pool
>>synced to the server's.  Is this right?
>
>Sure, but note the caveat that the attack has to see the results of
>"every read to /dev/urandom".  This might be true for IV's, but it
>would not be true for session keys, unless you have much, much larger
>problems.  The moment something unknown to the attacker is pulled ---
>say, a 128 bit session key the number of possible entropy pool states
>that the attacker would have to validate explodes, and it becomes
>roughly equivalent to a brute force attack of said 128-bit session
>key.  (Worse, actually, since we throw away half of the bits so the
>trying to maintain knowledge of the entropy pool sate after extracting
>128-bits not known to the attacker becomes equivalent to a 256 bit
>brute force attack.)

So, having a cron job which just reads /dev/urandom every second 
or so would make a good countermeasure. (I hope I have the Unix 
randoms correctly separated. I think random blocks, and urandom 
provides output by remixing a pool. MacOS only has urandom, but 
they call it random.)

I must say, I think people spend too much time trying to 
characterize the entropy available from ransom sources. In many 
cases, the estimates are quite inaccurate. However, if you have 
a good idea of the physical source of the

With most sources -- disk timings, network timings, Intel 
hardware, CPU temperature changes, Bill Cox's dongle, etc. etc, 
-- After you've gotten 100K bytes or so, there is no practical 
thing to worry about.

What is really daft is building your requirements so you need to 
generate SSH keys before these sources have had their chance to 
provide their input. One simple fix for SSH is to not generate 
the host's keys until the first SSH connection, or a fixed time 
delay, whichever happens last.

Cheers - Bill

-----------------------------------------------------------------------
Bill Frantz        |The nice thing about standards| Periwinkle
(408)356-8506      |is there are so many to choose| 16345 
Englewood Ave
www.pwpconsult.com |from.   - Andrew Tanenbaum    | Los Gatos, 
CA 95032



More information about the cryptography mailing list