Date: Mon, 26 Jun 2000 22:05:17 -0600 From: Warner Losh <imp@village.org> To: "Jeroen C. van Gelderen" <jeroen@vangelderen.org> Cc: Peter Wemm <peter@netplex.com.au>, Mark Murray <mark@grondar.za>, cvs-committers@FreeBSD.ORG, cvs-all@FreeBSD.ORG Subject: Re: cvs commit: src/usr.sbin Makefile src/usr.sbin/rndcontrol Makefile random.4 rndcontrol.8 rndcontrol.c Message-ID: <200006270405.WAA30439@harmony.village.org> In-Reply-To: Your message of "Mon, 26 Jun 2000 20:35:12 EDT." <3957F6C0.B8D8E006@vangelderen.org> References: <3957F6C0.B8D8E006@vangelderen.org> <20000626210416.324691CD7@overcee.netplex.com.au> <200006262227.QAA28257@harmony.village.org>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <3957F6C0.B8D8E006@vangelderen.org> "Jeroen C. van Gelderen" writes: : Urm, we're talking security here. The default should be false : unless the driver knows it's IRQ makes for a reasonable entropy : source. For shared IRQs you would need to "AND" all the : return values together. Of course you are right. The technique is still a valid one, none the less. : Eventually it may be better to have the device export an : entropy pseudo-device itself. We would need those for pure : entropy gathering devices anyway but even in the case of a : network driver it can be useful: the driver has access to : it's IRQ timings as well as network statistics from which : entropy can be distilled. The network driver could even : disable it's entropy device interface unless the link is : actually up and data is arriving. Actually, network drivers are not the best choices for entropy. They can be manipulated more easily by outside events. However, I'm not aware of an actual attack built on this theoretical weakness. Apart from custom hardware, the best entropy devices there are are keystrokes and mouse movement. Next comes disk I/O completion times (although they tend to be normally distributed, the jitter in the low order bits is generally fairly random). Network I/O can be useful, but is also prone to potential outside influance to a degree, so one must be careful there. Now that I think more about this, each device will have its own oddball kind of entropy. One idea would be to use an interface similar to the shutdown/suspend interface. Tell the nexus about any entropy that you've gathered (eg, here, mr nexus, are 12 random bits, please add them to the pool). The nexus would walk the tree giving all the devices the chance to use those 12 bits. Most devices would pass, but the entropy pool pseudo device would consume them. If we made this device attach to the nexus, or only had the nexus do its immediate children, we could optimize this tree walk in the time critial section that it would likely be called from (or we may have to set a pointer to *THE* entropy pool device and call it directly). This would put the onus of the entropy pool gathering in each device driver, but that might be OK since we potentially could wrap that in some common routines. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200006270405.WAA30439>