[onerng talk] /dev/random on Linux ...

[Bill Cox]

On Sat, Dec 20, 2014 at 7:55 PM, Jim Cheetham <jim at gonzul.net> wrote:
>
> Hi Bill.
>
> I thing that rngd is useful because it adds a level of protection
> against failure; if the data is not dirty enough, the source is
> rejected.
>

I hope to support rngd in the future, but it requires code changes to rngd,
and I didn't want to hold up releasing my TRNG while rngd is updated.
Also, enhancements to rngd can take years to propagate to the Debian stable
distro.

I use Keccak-1600 (SHA3) to whiten the data I write to the Linux entropy
pool.  Rngd would never find a failure.  Also, it's estimate of entropy is
very poor, as is ent and other entropy estimators.  I have a far more
accurate estimator in the health checker, and I drop any 512-bit samples
that have less than 400 bits of "surprise" entropy.  Each 512 bit sample is
written with ioctrl in one go, and I update the entropy estimate based on
how much I measured, or the predicted average "surprise" entropy, whichever
is lower.  This causes the state of the Linux entropy pool to recover to a
secure state after each write, with one remaining problem: I think the
reading of the compromised data continues until the 512 bits written are
reached.  As an option, I can generate any multiple of 256 bits from the
Keccac sponge.  The most secure method seems to be writing 4096 bits after
every 512 sample read from the TRNG, so that the entire state of the
entropy pool is securely scrambled.  That's how I would use it, but it does
slow it down.  The Linux rng code is not very fast.


> On Sun, Dec 21, 2014 at 10:23 AM, Bill Cox <waywardgeek at gmail.com> wrote:
> > Basically anyone using /dev/urandom effectively is
> > mounting a denial of service attack against people who need true random
> > data.
>
> Certainly that's what I used to believe, but is not the conclusion to
> draw from the description Thomas gave. So I asked Ted T'so, and I've
> got a whole load more detail from him that I need to get into my head
> now. When I've done that I'll get back to you :-)
>
> -jim
>
> --
>
>
Thanks.  I would like to know more about this issue.

Bill
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ourshack.com/pipermail/discuss/attachments/20141221/60338f3c/attachment.html>