On Tue, Jan 20, 2009 at 4:16 PM, Jack Lloyd <ll...@randombit.net> 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 _______________________________________________ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel