1996-02-07 - A Warning Re: Hardware RNG support for PGP 2.63

Header Data

From: Deranged Mutant <wlkngowl@unix.asb.com>
To: cypherpunks@toad.com
Message Hash: e6bbb870fe80d2b0fdca7145d70afbadc83402e7cef92fa243195f467dc633fa
Message ID: <199602071624.LAA20523@bb.hks.net>
Reply To: N/A
UTC Datetime: 1996-02-07 16:49:04 UTC
Raw Date: Thu, 8 Feb 1996 00:49:04 +0800

Raw message

From: Deranged Mutant <wlkngowl@unix.asb.com>
Date: Thu, 8 Feb 1996 00:49:04 +0800
To: cypherpunks@toad.com
Subject: A Warning Re: Hardware RNG support for PGP 2.63
Message-ID: <199602071624.LAA20523@bb.hks.net>
MIME-Version: 1.0
Content-Type: text/plain


-----BEGIN PGP SIGNED MESSAGE-----

rngaugp@alpha.c2.org wrote:

> Here is the README file that comes with the modifications.
> - ------------------------------------------
>                Hardware Random Number Support for PGP.
>                    PGP 263 international version
> 
> Ever get tired of typing in keyboard timing strokes while generating a
> PGP key? Ever want to use PGP unattended, but be foiled because there is
> no one there to type the keyboard timing strokes?
> 
> Ever wonder if PGP's method of generating random number might have some
> subtle flaw which would expose it to cryptanalysis?[..]

Ever wonder that a random number device driver or hardware will have a subtle 
flaw???

Relying on the /dev/random NOISE.SYS driver now while it's still in beta 
isn't nec. a good idea.  For experimentation, sure.  I'm also rather
concerned as to how this version of PGP handles it.  Very much so.

The current and latter versions of NOISE.SYS parallels the Linux random.c 
driver in that there are two devices, /dev/random and /dev/urandom... the 
older versions (pre version 0.4) will return as many bytes as are requested 
(from /dev/random) whereas the current version returns only as many bytes as 
are conservatively estimated to be "truly random".

If you are using the older NOISE.SYS /dev/random or the newer version's 
/dev/urandom for key generation then essentially you're using a pseudo-RNG 
based on SHA rather than real random data.

The implementation should try to get as many bits as are needed from the 
driver and then request some keystrokes, collect more data, etc. until you 
have enough bits (advantage over older PGP method? You only need to sample 
from driver, and not worry about processing raw samples yourself; driver also 
samples from other sources than keystrokes as well...)

I'd be wary of relying on NOISE.SYS or any similar driver for PGP-key 
generation until the driver gets more thorough examination; I'd also be VERY 
wary of an improper use of the driver.


- --Rob (who wrote NOISE.SYS).
- ---
[This message has been signed by an auto-signing service.  A valid signature
means only that it has been received at the address corresponding to the
signature and forwarded.]

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
Comment: Gratis auto-signing service

iQBFAwUBMRjSNSoZzwIn1bdtAQEn+wF/ZxQKqOCRyKrJjmdtYtE2kVG6v+3NkOOb
84JMpWkpzkMVe8L7LHr7bLdgzkVxDB+8
=m54+
-----END PGP SIGNATURE-----





Thread