On 11/11/2013 10:30 PM, James A. Donald wrote: > Obviously what we need is something that blocks until it has > accumulated 128 bits of entropy, generates pseudo random output from > its existing state, and never blocks thereafter. From time to time, > not very often at all, it reseeds by adding an addtional 128 bits of > entropy all at once. > > However, people complain that if any of the existing sources of > randomness are fixed to work like that, it is not bug compatible and > will break existing software. > > So: Create a new source of randomness, xrandom, which is like > urandom, except for the bug.
Sorry, the problem is muuuuch harder than that. If the solution were that simple and that obvious, it would have been implemented a long time ago. The fact is, there are some applications that cannot make do with low-quality randomness *and* cannot afford to wait. -- A PRNG that puts out low-quality randomness causes insidious failures. -- A PRNG that blocks causes manifest failures. It could be argued that trading an insidious failure for a manifest failure is a step in the right direction, but it is only a small step, and it does not solve the main problem. We need a PRNG that /always/ puts out a cryptographically-strong random distribution ... early in the boot-up process and at all times thereafter. Specific constructive suggestions for how to do this have been put forward ... such as putting a seed in the kernel boot image, and making sure the seed is properly provisioned. If/when we have a PRNG that is always ready to use, the question of blocking does not arise, and there is no need to define a new interface. _______________________________________________ RNG mailing list [email protected] http://lists.bitrot.info/mailman/listinfo/rng
