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

[Bill Cox]

On Wed, Jan 20, 2016 at 1:05 PM, Theodore Ts'o <tytso at mit.edu> 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.)
>
>                                    - Ted
>

I guess if this were a significant attack vector, someone would patch it.
It is simply a well known minor flaw  that makes my list, and for which I
code around by writing a bunch of random bits all at once rather than
trickling them in.  Rngd gets this detail right, and other entropy
gatherers should be aware of it.

Bill
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20160120/d07acf78/attachment.html>