From: hfinney@shell.portal.com (Hal Finney)
Date: Mon, 29 Nov 93 08:52:02 PST
To: cypherpunks@toad.com
Subject: Re:  Cryptosplit 2.0
Message-ID: <9311291648.AA25233@jobe.shell.portal.com>
MIME-Version: 1.0
Content-Type: text/plain


From: m5@vail.tivoli.com (Mike McNally)
> On UNIX systems, where keystroke timing can be problematic, couldn't a
> collection of various system metrics be used to provide a bunch of
> reasonable pseudo-random bits?  Things like:
> 
> *	Disk space in /
> *	Network activity (in/out packet counts)
> *	load average
> *	swap space available
> *	time of day (duhh)

These can play a role in seeding a RNG, but there is probably not as
much randomness there as you might expect.  Knowledge of the approximate
time of day the program was run, plus some general information about the
characteristics of your system in terms of usage, can probably pin most
of those values down to within a factor of 5 or so.

I think multiple MD5 hashes of the total contents of /tmp (or, better,
/swap, if you can access that) would have more bits of randomness.  In
any case, Shamir sharing requires a LOT of random bits ("k" times the
size of the file) so at best these sources of randomness could seed a
RNG, which would then "amplify" the randomness (in a cryptographic
sense) to produce the random bits needed for the sharing algorithm.

I believe the RIPEM public key package by Mark Riordan has a fairly wide
repertoire of techniques for searching for randomness, including some of
the above ideas.  This code might be worth adapting to a general-purpose
entropy-seeking algorithm.  The problem is that these kinds of things are
highly system dependent.  If you have an audio port, for example, listening
to an unconnected microphone can produce a steady stream of noise.  Or if
you have a high-speed timer it can be used to get perhaps a couple dozen
bits of randomness at program-startup time, or to get many bits per keystroke.
So you have to have customization for each target system to be useful.
I do think the RIPEM code would be a good starting point, though.

I once proposed a DOS TSR (a "background" program) which would monitor
your keystrokes all day long and condense the timing data into a file
full of random bits.  Then you'd use up the bits when you needed to do
cryptography.  I haven't learned enough about DOS to write such a
thing, though.

Hal Finney
hfinney@shell.portal.com