From dtd@world.std.com Sat Apr 22 09:40:21 PDT 2000 Article: 5462 of isaac.lists.cryptography Path: news.isaac.cs.berkeley.edu!not-for-mail From: Don Davis Newsgroups: isaac.lists.cryptography Subject: Re: Entropy-gathering gizmos for Solaris? Date: 19 Apr 2000 13:55:26 -0700 Organization: ISAAC Group, UC Berkeley Lines: 65 Sender: daemon@abraham.cs.berkeley.edu Approved: mail2news@news.isaac.cs.berkeley.edu Distribution: isaac Message-ID: References: <200004182159.OAA08683@breakaway.Stanford.EDU> NNTP-Posting-Host: abraham.cs.berkeley.edu Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" In-Reply-To: <200004182159.OAA08683@breakaway.Stanford.EDU> Xref: joseph.cs.berkeley.edu isaac.lists.cryptography:5462 > Ok, now I'm curious about what all entropy-gathering gizmos, ... > might be available for/on Solaris -- anyone know? the solaris security toolkit has a program called cryptorand. about 3-4 years ago, i intensively reviewed and tested crypto- rand for a client. i talked a lot back then with bill soley, the sunsoft engineer who designed and wrote cryptorand, and bill gave me a lot of detail about how the program worked. because i've worked on true RNGs myself, i was very interested in bill's approach. cryptorand is an application program that reads kernel memory pages from kmem, hashes the pages into an entropy pool, and exports the pool's bits via a pseudo-device driver. crypto- rand is careful to skip a page if the page hasn't changed since the last time it was examined. the program also saves its entropy pool to disk on shutdown, so that the program is sure to have a different starting state at every reboot. bill was very conservative about not publushing too many bits, and about rejecting pages that might not have changed. i found that cryptorand could produce kbytes of key-quality bits per second, and that it was pretty efficient. when i pulled bits out as fast as possible, while a web server was answering http requests on the same machine, i saw a ~5% reduction in the web-server's throughput. i concluded that this 5% hit really came not from cpu load, but from memory- bus contention. anyway, the test was perhaps not perfectly realistic, because a server wouldn't need to pull bits out as fast as i did. i also did some statistical testing of cryptorand's output, though this was unnecessary; cryptorand uses md5, which is well-known to produce white noise. finally, i disabled crypto-rand's state-saving feature, and rebooted the machine a few hundred times, saving cryptorand's first few bytes from each reboot. i then checked these initial bytes for entropy and for correlations, and found no problems. here's why i believe it's reasonable to say that cryptorand's output qualifies as true entropy. at boot time, the unix kernel's memory comprises several tables, most of which are set up as linked lists of control structures, waiting to be allocated. in use, these structures are extensively cross- linked to one another with pointer spaghetti. when a table element is freed, it is added to the top of its table's free list, so that the free-list is shuffled by the kernel's activ- ity. since the kernel's activity is strongly i/o-driven, the kernel's history of i/o timing is recorded in the particular tangle of pointer spaghetti, in both the active table struc- tures and in the free-lists. btw, i got bill's permission to send these comments to the list. - don davis, boston http://world.std.com/~dtd -