People interested in this topic who aren't familiar with RFC 1750,
"Randomness Recommendations for Security", should probably take a look at
it. It's available from all the usual RFC sources, such as
www.rfc-editor.org.
Besides a useful discussion of randomness and pseudo-randomness in security
applications, the RFC covers several potential entropy sources and their
limitations, and describes common techniques for distilling entropy and
removing bias.
Here are a couple more techniques for generating some entropy. Like the
ones Lutz and Bill have been discussing, they have drawbacks - in
particular, there's no guarantee how much entropy they'll produce, or how
quickly.
1. For experimental purposes, I've used a simple non-crypto PRNG in a daemon
that "wastes" a (hopefully unpredictable) part of the stream. Several times
a second the daemon generates the next number in the stream and stores it
until it generates again. It has a named pipe (FIFO) open for writing; when
another process opens the pipe for reading, the daemon writes the stored
value to the pipe (in text, to make it easy to use in scripts). The daemon
always discards a few (1-16, based on the next value out of the generator)
values before it will write another value to the pipe, regardless of whether
a process is trying to read from it. If the PRNG has significantly more
state than is contained in a single value, and the pipe is sampled
infrequently relative to the daemon's sleep time (say, 200ms, so it discards
five values a second), and the times between samplings are unpredictable,
then it's relatively difficult to determine the state of the PRNG. If the
system is sufficiently loaded that the daemon frequently sleeps longer than
the minimum time, that helps too. Unfortunately this method is inherently
slow.
2. The SRP distribution includes (or used to include, as of version 1.4.4)
CryptoLib 1.1, by Jack Lacy, Don Mitchell, and Matt Blaze. CryptoLib uses a
"roulette" system to generate entropy: it has a tight loop increment a
counter until a timer interrupt (set to 16665us) stops it. Then it does
some bit-mixing on the counter value and takes three bits of the result. It
does this several times to get a 32-bit value. The authors suggest that
this yields about 16 bits of entropy per 32-bit value, but possibly biased
and non-uniformly distributed, so they recommend post-whitening (eg. using a
cryptographic hash). They say their testing reveals decent results even on
unloaded machines. The method should produce a 32-bit value in about 185
ms, system load permitting, not counting post-whitening. See
unix_truerand.c and the similar nt_truerand.c in the CryptoLib distribution.
The CryptoLib 1.1 document file says the source code can be obtained by
sending email to [EMAIL PROTECTED] with a statement of the form:
"I am a U.S. or Canadian citizen or a legal permanent resident of the
U.S. and am aware that some parts of CryptoLib may be restricted under
United States Export regulations. I have read and understand the
CryptoLib license."
Name:
Location:
E-mail:
Are you licensed to use the RSA patent?
If yes, give name of licensed organization:
Since some of the relevant legalities have changed (particularly the RSA
patent issue), the terms may now be different. In any case, the PRNG and
RNG components should be unencumbered and the CryptoLib authors may be
willing to make them available for download, if they aren't already.
The CryptoLib authors admit that their RNG has not been rigorously studied
(the Cryptopane Yarrow generator is the only one I know of where the
designers *have* tried to demonstrate its suitability for crypto), and
advise augmenting it with human-generated randomness when possible. But I
think it's an interesting system that's worth trying, particularly if you're
combining it with other unrelated entropy sources.
Of course, as always it's important to keep your threat model and the
security of the whole system in mind. Sure, random number generation was
famously the downfall of the original Netscape SSL implementation, and it's
worth thinking carefully about. But at some point your (P)RNG will become a
more difficult target than some other part of the system, and a clever
attacker will go after the low-hanging fruit. RAND_screen() doesn't seem
sufficient to me, but throw another entropy source or two in with it and it
becomes unlikely that someone will try to predict the generator output.
Instead they'll look for exploitable web server and CGI bugs that give them
unauthorized database access so they can dump credit card numbers right from
your server, for example. (Look at the IIS + Access bugs that let people
submit arbitrary SQL queries against web front-ended databases. That's a
hell of a lot easier than breaking an SSL session by trying to predict the
PRNG.)
Gather ye entropy while ye may, but don't make it an obsession. You may
overlook something else.
Michael Wojcik [EMAIL PROTECTED]
MERANT
Department of English, Miami University
> -----Original Message-----
> From: Lutz Jaenicke [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, January 24, 2001 4:14 AM
> To: [EMAIL PROTECTED]
> Subject: Fwd: [Gathering Entropy quickly for openSSL]
>
>
> Hi!
>
> I am currently in a discussion with Bill Browning about entropy gathering
> and as suggested I would like to share the discussion with the forum both
> for others to be informed and to get more input on it.
>
> Best regards,
> Lutz
[interesting discussion snipped]
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
