>>>>> "Osma" == Osma Ahvenlampi <[EMAIL PROTECTED]> writes:
Osma> Looking at this discussing going round and round, I'm very
Osma> inclined to fetch the latest freeswan-snapshot, grep for
Osma> /dev/random, and replace all reads with a routine that has it's
Osma> own internal Yarrow-like SHA mixer that gets reseeded from
Osma> /dev/random at semi-frequent intervals, and in the meantime
Osma> returns random numbers from the current SHA value. That's how I
Osma> believe /dev/random was intended to be used, anyway...
No, that's how /dev/urandom was intended to be used.
What you describe duplicates the functionality of /dev/urandom. Why
do it?
I agree with Ted that there may well be people that misuse
/dev/random. If so, the obvious comment is RT*M. Perhaps the
documentation may want to emphasize the intended use of /dev/random
more strongly. (Come to think of it, it's not clear to me especially
after reading the Yarrow paper that there really *are* cases where the
use of /dev/random rather than /dev/urandom is actually warranted.)
Re Henry Spencer's comment:
>On Tue, 3 Aug 1999, bram wrote:
>> The goal is to make it so that any time someone wants random numbers they
>> can go to /dev/random, with no required studying of entropy and threat
>> models and all that yadda yadda yadda which most developers will
>> rightfully recoil from getting into when all they want is a few random
>> bytes.
> That, surely, is what /dev/urandom is for. (Maybe /dev/random ought to
> be mode rw-------, so that only root applications can use it?)
That may reduce the number of applications that blindly use
/dev/random without knowing why this isn't the right thing to do. On
the other hand, it won't prevent applications that read /dev/urandom
from causing those that use /dev/random to block (so long as both
continue to use the same pool.
Then again, if the valid uses of /dev/random are somewhere between
rare and non-existent, which seems to be the case, this is a
non-issue.
Finally, from Bram:
> 5) a (very small) amount of persistent memory to keep pool state in (or at
> least periodically put some random bytes in to put in the pool at next
> reboot.) It would have to be plugged into a trusted piece of hardware to
> give it real randomness at least once, of course, but that wouldn't be a
> big deal.
That doesn't solve the issue of entropy sources on diskless UI-less
systems. All it does is let you carry whatever you got across
reboots. If you have none to carry, you still have an issue.
I do agree that using any available NV memory for keeping pool state
across reboots is a good thing.
paul
