Bugtraq mailing list archives
Re: /dev/random is probably not
From: "Zow" Terry Brugger <zow () llnl gov>
Date: Sun, 03 Jul 2005 12:39:30 -0700
- Linux? (I don't think so, If we have network and other I/O device such as keyboard, I thought that would be used, too. but I want confirmation from people in the know.)
It's been a while since I looked at the /dev/random design on Linux (probably the early 2.4 days), however one thing that was quite clear was that they did not use any network I/O as entropy sources because an attacker, particularly one that already had control of other machines on the same LAN segment, could have a high degree of control over that source. I would be most interested if that has changed since the last time I looked at it.
OpenBSD, FreeBSD, NetBSD and the like, and of course
Checking the /dev/random manpage on Darwin, it indicates that entropy is input from the system "Security Server", which uses "kernel jitter". Unfortunately, a quick check did not reveal exactly what the source of this kernel jitter is. Never-the-less, the manpage does indicate that this /dev/random design is from FreeBSD and likely shared with other BSDs.
Windows family OSs.
All I can observe here is that F-secure SSH still (at least the most recent version I've used) collects its own entropy when running on Win2K, which indicates to me that either they want to operate the same on all Windows versions (as memory serves, Win95/98 does not have a RNG), or that Win2k does not have a suitable RNG.
One of these days, on desktop PCs, we could add the reading of diode used for measuring CPU temperature to the mix of entropy source. (Of course, we need a good source of `entropy' to begin with, and adding another source such as diode is a good thing IMHO.) And maybe the fan rotation/speed, too. I found that they change constantly on my PC!
You would only want to use one or the other, since the fan rotation is a function of the CPU temperature measurement -- if you used both you would essentially be entering the same measurement into the RNG twice, which isn't very random.
Some of these CPU-bound devices may have implications when we have a dual core CPU. Reading of such device by one thread may be highly predictable by another thread running on the CPU chip.
Indeed -- certainly the recent advisory regarding information leakage through the cache between threads on multi-core CPUs (CVN: CAN-2005-0109) indicates that we're starting to find problems of this nature already. Cheers, Terry #include <stddisclaim.h>
Current thread:
- Re: /dev/random is probably not, (continued)
- Re: /dev/random is probably not Chiaki (Jul 02)
- Re: /dev/random is probably not exon (Jul 04)
- Re: /dev/random is probably not Darren Reed (Jul 05)
- Re: /dev/random is probably not devnull (Jul 06)
- Re: /dev/random is probably not Thomas (Jul 06)
- Re: /dev/random is probably not Darren Reed (Jul 06)
- Re: /dev/random is probably not Thomas (Jul 06)
- Re: /dev/random is probably not Kai Howells (Jul 08)
- Re: /dev/random is probably not Stefan Bethke (Jul 08)
- Re: /dev/random is probably not exon (Jul 04)
- Re: /dev/random is probably not Francesco Messineo (Jul 12)
- Re: /dev/random is probably not Chiaki (Jul 02)
- Re: /dev/random is probably not Anton Ivanov (Jul 05)
- Re: /dev/random is probably not devnull (Jul 06)
- Re: /dev/random is probably not Chris Kuethe (Jul 06)
- Re: /dev/random is probably not Thomas (Jul 06)