[147765] in cryptography@c2.net mail archive
Re: [Cryptography] [RNG] on RNGs, VM state, rollback, etc.
daemon@ATHENA.MIT.EDU (Kent Borg)
Sun Oct 20 13:31:04 2013
X-Original-To: cryptography@metzdowd.com
Date: Sun, 20 Oct 2013 12:54:28 -0400
From: Kent Borg <kentborg@borg.org>
To: cryptography@metzdowd.com
In-Reply-To: <5263A240.6060904@iang.org>
Errors-To: cryptography-bounces+crypto.discuss=bloom-picayune.mit.edu@metzdowd.com
On 10/20/2013 05:28 AM, ianG wrote:
> Good example. I'm going to get off the fence and say that the RNG
> should never block.
The RNG should be configurable to block.
In the case of Linux's urandom Ted suggested blocking on bits-in and
time, which ever comes first. The question of defaults becomes key.
I suggest that the kernel's default values for these two parameters
should be small enough that nearly no existing user is harmed by the
change, yet many could benefit from not running on empty immediately
after boot.
One question I have is who are typical first users of urandom after
boot? (That is, who will notice if the delay in seconds or bits is too
large, what are they doing, when are they doing it?)
At the larger system level, these parameters could be set explicitly
according to what that system is doing, how it is designed, etc.
-kb
_______________________________________________
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography
