On Fri, Dec 09, 2011 at 12:14:40PM -0500, Thor Lancelot Simon wrote: > > Let me put it this way: before, you may have thought you were getting > some kind of "true" randomness. You weren't. Now, you still aren't, > but at least what sits between you and the entropy source is a lot > more clear, and a lot better analyzed.
I should point out that there is one other thing we could do to supply more entropy per output byte, and cause callers who may not be getting as much entropy as they asked for to block. I have been trying to follow the Yarrow/Fortuna design paradigm of rekeying the stream generator from the entropy pool at each "request". After thinking about how applications actually use this interface at some length I decided the right scope for a "request" was probably an open/close of the device node. This also kept the code for /dev/urandom and /dev/random extremely similar, which facilitates analysis of the implementation. However, when applications use /dev/random, we could consider a "request" to be a single read from the device. This also has the appealing property that it aligns with how the underlying generator (CTR_DRBG) counts "requests". That way, in practice, each read from /dev/random would get a fresh AES key -- and most application reads from /dev/random, which may block, are very small. I think that, in practice, that is about as close to meeting the expectations of the application authors as possible. Thor
