Date: Mon, 30 Oct 1995 20:16:24 +0200 From: Mark Murray <mark@grondar.za> A colleague drew my attention to this, and I was so pleased with it that I ported it to FreeBSD. Which version did you grab? More recent versions of the driver use a more efficient mixing algorithm suggested by Colin Plum. There's also the beginnings of support for user-mode deamons to add randomness into the random pool by writing to /dev/random. I also added support for reading the instruction timing register for x86 platforms that support it. 2) We felt that hooking all interrupts might be dangerous. IDE drives can interrupt at a heck of a rate, and so can some serial ports, and we felt that in these cases _not_ using the interrupt was a good idea. So I added an ioctl to allow the superuser to select his own set, appropriate to the hardware in use. It is nearly impossible to do this automatically. Indeed; I can't emphasize this enough. The clock interrupt, for example, is a very bad irq to try to use. In the Linux driver, only device drivers who register their interrupt driver with the SA_SAMPLE_RANDOM flag actually have the interrupt timings sampled for the random number generator. People have suggested using making it possible to select at run-time which interrupts to sample, instead of at compiling it into the device drivers. I've generally not been convinced this is a good idea, because most system administrator won't likely know which irq's are good and which are bad for random number generation. For example, although it may not be obvious, the network interrupt may not be a good choice, since an adversary who is monitoring the ethernet cable can make a pretty good guess about the timing of your network interrupts, and hence what the likely inputs are to the random number pool might be. Gimme a yell if you want copies :-) Sure, why not. I'd be interested to see what you did. - Ted