[Cryptography] /dev/random is not robust

[Sandy Harris]

Derrell Piper <ddp at electric-loft.org> wrote:

> See also Ted's response here:
>
> https://news.ycombinator.com/item?id=6548893

Yes. it is not at all clear that their analysis actually matters:

>From the paper:

" Several security notions have been defined:
" – Resilience: an adversary must not be able to predict future PRNG
outputs even if he can influence the entropy source used to initialize
or refresh the internal state of the PRNG;
" – Forward security ( resp. backward security): an adversary must not
be able to predict past (resp. future) outputs even if he can
compromise the internal state of the PRNG.
" ... Barak and Halevi [BH05] model a PRNG with input ... and define a
new security property called robustness that implies resilience,
forward and backward security. This property actually assesses the
behavior of a PRNG after compromise of its internal state ...

None of this matters much if the enemy does not already have root on
your system. If an enemy does have root, he has far better targets
than the RNG available and the defenders have bigger worries. Without
root, he cannot see the internal state and, if you use the typical
setup where some saved entropy from last time is pumped in by the boot
scripts, he cannot read that file and using it seems to complicate the
state enough for security. It would take a completely different
analysis including a very clever new attack to show a problem there,
and this paper does not even attempt that. Moreover, having looked at
the driver internals, I do not think it is even possible.

Also, the definition of resilience mentions an adversary who "can
influence the entropy source" but the random(4) driver uses multiple
sources so the degree of influence is generally limited. There are
cases where this is a serious concern -- for example a router does not
have keyboard, mouse or hard disk, some skip the initialisation from a
file and an enemy can monitor or even control network inputs. However,
those are fixable; just using a file of saved entropy goes a long way
toward solving the problem.

There are a number of good ways to get additional entropy sources. My
attempt at writing one and a paper that comments on several others are
here:
ftp://ftp.cs.sjtu.edu.cn:990/sandy/maxwell/

Another along similar lines but not mentioned in that paper is:
http://www.chronox.de/jent/doc/CPU-Jitter-NPTRNG.html