[17600] in cryptography@c2.net mail archive

home help back first fref pref prev next nref lref last post

Re: /dev/random is probably not

daemon@ATHENA.MIT.EDU (John Denker)
Fri Jul 1 18:04:38 2005

X-Original-To: cryptography@metzdowd.com
X-Original-To: cryptography@metzdowd.com
Date: Fri, 01 Jul 2005 17:28:58 -0400
From: John Denker <jsd@av8n.com>
To: "Charles M. Hannum" <root@ihack.net>
Cc: cryptography@metzdowd.com
In-Reply-To: <200507011708.50277.root@ihack.net>

On 07/01/05 13:08, Charles M. Hannum wrote:
> Most implementations of /dev/random (or so-called "entropy gathering
> daemons") rely on disk I/O timings as a primary source of randomness.

>  ... I believe it is readily apparent that such exploits could be 
> written.

So don't do it that way.

Vastly better methods are available:
   http://www.av8n.com/turbid/

ABSTRACT: We discuss the principles of a High-Entropy Symbol Generator
(also called a Random Number Generator) that is suitable for a wide
range of applications, including cryptography and other high-stakes
adversarial applications. It harvests entropy from physical processes,
and uses that entropy efficiently. The hash saturation principle is used
to distill the data, resulting in virtually 100% entropy density. This
is calculated, *not* statistically estimated, and is provably correct
under mild assumptions. In contrast to a Pseudo-Random Number Generator,
it has no internal state to worry about, and does not depend on
unprovable assumptions about ``one-way functions''. We also describe a
low-cost high-performance implementation, using the computer's audio I/O
system.

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com

home help back first fref pref prev next nref lref last post