Re: [Monotone-devel] Re: nvm.stripped versus botan

[Zack Weinberg]

On Tue, Jan 20, 2009 at 4:16 PM, Jack Lloyd <address@hidden> wrote:
> ... while
> an entropy source can claim it works or not, in the sense that it will
> produce some output, it really has no way of knowing if that output is
> in any way random/unguessable by an attacker, which is really the
> purpose of this code.
>
> For instance in the case of /dev/random - normally it's probably good
> enough on its own, but at the same time I audited several
> implementations (mostly in fairly obscure OSes, admittedly), that
> turned out to have very weak implementations (RC4 seeded with boot
> time, or even worse). And personally I do not trust the
> implementations in, for instance, Linux or FreeBSD to actually live up
> to their claim that 1 bit of /dev/random output contains 1 bit of
> conditional entropy (the paper "Analysis of the Linux Random Number
> Generator" contains some analysis on this topic for Linux -
> http://www.pinkas.net/PAPERS/gpr06.pdf).
>
> That said, it's no good to slow mtn startup down so much since that is
> clearly not the Right Thing either.

Do you think we could get away with skipping es_unix if we have
something else, though?  That's the really slow one.

The author of the Linux /dev/random responded to that paper here:
http://lkml.indiana.edu/hypermail/linux/kernel/0605.2/0299.html

and if you check
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=history;f=drivers/char/random.c;h=7c13581ca9cd6ac1ea4a2d54e80397831cebd75f;hb=HEAD
you can see that there have been a whole bunch of fixes since the
paper was written, although I can't tell if any of them specifically
address the authors' concerns.

zw