[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