From owner-cvs-all Mon Jun 26 23:27:55 2000 Delivered-To: cvs-all@freebsd.org Received: from grimreaper.grondar.za (grimreaper.grondar.za [196.7.18.138]) by hub.freebsd.org (Postfix) with ESMTP id A83F137B948; Mon, 26 Jun 2000 23:27:41 -0700 (PDT) (envelope-from mark@grondar.za) Received: from grimreaper.grondar.za (localhost [127.0.0.1]) by grimreaper.grondar.za (8.9.3/8.9.3) with ESMTP id IAA54693; Tue, 27 Jun 2000 08:27:43 +0200 (SAST) (envelope-from mark@grimreaper.grondar.za) Message-Id: <200006270627.IAA54693@grimreaper.grondar.za> To: Warner Losh Cc: "Jeroen C. van Gelderen" , Peter Wemm , Mark Murray , 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 References: <200006270405.WAA30439@harmony.village.org> In-Reply-To: <200006270405.WAA30439@harmony.village.org> ; from Warner Losh "Mon, 26 Jun 2000 22:05:17 CST." Date: Tue, 27 Jun 2000 08:27:42 +0200 From: Mark Murray Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Of course you are right. The technique is still a valid one, none the > less. Please have a look at the Yarrow paper at www.counterpane.com. > 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. As long as your entropy estimate is good enough, this works very well. > 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. I only marginally understand this. Help, please? :-) (I need to understand what the code to do the nexus attach would look like). > 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. Sounds cool. M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message