On Mon, 17 Sep 2007 03:10:30 -0700 "Ted Mittelstaedt" <[EMAIL PROTECTED]> wrote:
> > > > -----Original Message----- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] Behalf Of RW > > Sent: Sunday, September 16, 2007 7:24 PM > > To: email@example.com > > Subject: Re: /dev/random question > > > > > > On Sun, 16 Sep 2007 23:51:56 +0200 > > Mel <[EMAIL PROTECTED]> wrote: > > > > > On Sunday 16 September 2007 22:55:50 RW wrote: > > > > On Sun, 16 Sep 2007 15:21:38 +0200 > > > > > An applicatation using /dev/random doesn't see the difference. It > > > was necessary at the time, because systems couldn't produce enough > > > entropy, so they could put the application on hold till more was > > > available. All the application wants is randomness and it accounts > > > for the fact that it can be blocked, yet it never gets blocked so > > > it's happy(tm) either way. > > > > > > Also, I can't see how you can usefully improve on /dev/random > > > other then getting rid of the blocking, so applications don't > > > have to account for it. > > > > > > > Using Yarrow for /dev/random is not an intrinsically bad idea, > > > > but it is controversial. > > > > > > Removing /dev/random all together would be controversial. This is > > > just backwards compatibility. Nothing changed as far as a consumer > > > of /dev/random is concerned. > > > > It's not about interfaces or performance - it's about security. > > > > The difference is that Yarrow is a PRNG that reuses the same 160 > > bits of entropy until it reseeds itself. A traditional /dev/random > > will output fewer random bits than it get in as interrupt entropy > > (a good implementation will be conservative about this). A lot of > > people prefer the latter approach for critical things like key > > generation. > > > > Understood but this was already known by the authors of the > FreeBSD /dev/random device. > > If the system is running on the software generator (yarrow) the > generator is reseeded from entropy gathered from the system. The > lan, serial, hardware and software interrupts in the system all > supply entropy. If for some reason the PRNG cannot gather enough > entropy fast enough to reseed then the status of the sysctrl > > kern.random.sys.seeded > > changes from 1 to 0 and the /dev/random device will start blocking > until entropy allows a reseed OR a process with superuser privileges > writes something to the random device which will be used for reseed. > This is documented in the man page. You didn't read it carefully enough (although the page isn't very clear). Yarrow starts-off blocked; when it's accumulated a certain amount of entropy (usually from the entropy file) it unblocks and "kern.random.sys.seeded" switches from 0 to 1. It will *never* switch back to zero of its own accord. What the man page is saying is that if you set "kern.random.sys.seeded=0" the device will return to the initialization state where it waits for enough entropy to unblock again. > Now I hear you saying "Ah ha - so the FreeBSD random device does > block after all" Well, yes and no. In most random devices under > UNIX they are very slow. So it is easy for the system to overrun > the random device. But Yarrow is fast enough so that the question > of blocking becomes theoretical, not practical. I've run randomness > test programs on a number of FreeBSD systems with the Yarrow-based > driver that were doing nothing else and the device has never > blocked. This is based on the misconception that Yarrow will block when it runs short of entropy - it doesn't, it simply reuses it indefinitely. > ... > > ... > > With FreeBSD 6.2 both files will be filled by Yarrow and it's likely > > that the end of ./dvd and the whole of ./keyfile will come from the > > same Yarrow pseudo-random sequence. If enough of the random data > > survives at the end of the dvd it may allow an attack against the > > PRNG. > > > > No, it wouldn't. The PRNG attacks are dependent on the PRNG being > bad enough that the algorithim favors certain groups of numbers > regardless of the seed being fed to it. > ... > > As things stand, Yarrow is secure, but it might not be a few years > > from now. > > > > That's true for all encryption assuming computing power continues to > grow by leaps and bounds. My point was that Yarrow may have weaknesses that we don't yet understand. _______________________________________________ firstname.lastname@example.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"