|
|
|
|
|
|
|
|
|
|
|
|
| home | help | back | first | fref | pref | prev | next | nref | lref | last | post |
X-Original-To: cryptography@metzdowd.com Date: Mon, 11 Nov 2013 23:44:16 -0700 From: John Denker <jsd@av8n.com> To: jamesd@echeque.com, cryptography@metzdowd.com, RNG mlist <rng@lists.bitrot.info> In-Reply-To: <5281BCEA.509@echeque.com> Errors-To: cryptography-bounces+crypto.discuss=bloom-picayune.mit.edu@metzdowd.com 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. _______________________________________________ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
|
|
|
|
|
|
|
|
|
|
|
|
| home | help | back | first | fref | pref | prev | next | nref | lref | last | post |