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

[Jack Lloyd]

On Tue, Jan 20, 2009 at 02:31:30PM -0800, Zack Weinberg wrote:

> Jack  - Can we get this fixed in botan?  It seems to me that the Right
> Thing is for each entropy source to report whether it works on a
> particular system, and then for the RNG object to use only the first
> one that works.  Thus, if we've got /dev/random we don't even look for
> EGD, if we've got EGD we don't try the programs, and so on.

I don't think I buy that this really is the Right Thing, because 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.

> Also, I'm confused about the use of high-resolution timers as entropy
> sources -- it seems like they don't belong, or at least ought to be
> subordinated to the "real" entropy sources.  Maybe the idea is to
> avoid dipping into the more expensive entropy pools as much?  Only I'm
> not sure I trust rdtsc (e.g.) to give entropy *at all*...

The current approach, as you know, is highly kitchen sink. That is
why, for instance, rdtsc/rpcc/etc is used - it's basically free
(especially compared to the alternatives, which at a minimum will make
a syscall) and it _might_ well provide a nibble or two of entropy,
especially if the local machine is safe and attackers only have remote
acess. The PRNG is designed such that even if some or most of the
inputs are known, guessed, or chosen by an attacker, as long as some
sufficient amount is not known/guessable the PRNGs output will also
remain hard to guess.

-Jack