1993-11-30 - Re: Cryptosplit 2.0

Header Data

From: Brad Huntting <huntting@glarp.com>
To: cypherpunks@toad.com
Message Hash: 191277b8f7f4046aff87a89cb7e1d4220c8ab3da9c1e64be9a6818d05a3719ce
Message ID: <199311300256.AA05265@misc.glarp.com>
Reply To: <9311291648.AA25233@jobe.shell.portal.com>
UTC Datetime: 1993-11-30 02:57:16 UTC
Raw Date: Mon, 29 Nov 93 18:57:16 PST

Raw message

From: Brad Huntting <huntting@glarp.com>
Date: Mon, 29 Nov 93 18:57:16 PST
To: cypherpunks@toad.com
Subject: Re: Cryptosplit 2.0
In-Reply-To: <9311291648.AA25233@jobe.shell.portal.com>
Message-ID: <199311300256.AA05265@misc.glarp.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:

> 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.

If I remember coorectly it's KerberosV uses an MD5 hash of /dev/mem.
This covers everything reported by "ps", "netstat", "iostat",
"vmstat", "pstat", and a lot more kernel stuff that's very difficult
to predict for any machine that's up and running on a busy network
for more than a few hours.

Still, probably not 128 bits worth of entropy.


brad





Thread