1993-11-23 - Re: Can NSA crack PGP?

Header Data

From: Derek Atkins <warlord@MIT.EDU>
To: karn@qualcomm.com (Phil Karn)
Message Hash: 992f94823b7a3c0eb21dec91e27fef5ad014b52a73caa21d6d4b2524c2d1624b
Message ID: <9311230920.AA13996@oliver.MIT.EDU>
Reply To: <199311230859.AAA05134@servo>
UTC Datetime: 1993-11-23 09:22:44 UTC
Raw Date: Tue, 23 Nov 93 01:22:44 PST

Raw message

From: Derek Atkins <warlord@MIT.EDU>
Date: Tue, 23 Nov 93 01:22:44 PST
To: karn@qualcomm.com (Phil Karn)
Subject: Re: Can NSA crack PGP?
In-Reply-To: <199311230859.AAA05134@servo>
Message-ID: <9311230920.AA13996@oliver.MIT.EDU>
MIME-Version: 1.0
Content-Type: text/plain

> I think this is less of a problem. Given a good cryptograpic hash
> function, I would simply hash *all* of the clock bits, without regard
> to which are the "hottest" ones. If (important 'if') there is
> sufficient total entropy in the input bits, hashing should effectively
> "distill" the input entropy into the output bits.

True.  In fact, PGP does this.  However, the problem is knowing how
much raw data you need in order to get enough entropy into the system.
That is the hardest part.  For example, say that only one bit is
random for every 8 you get.  That is a very big difference than if 6
of the 8 bits were truely random.  And each machine-type is different!

Yes, you don't really need to know which bits are the hot-bits, but
you need to know how many hot-bits/byte you have, and this is machine
specific.  You could always deal worst-case, in which you assume the
worst machine-type and on machines with better hot-bit ratios you just
get extra entropy.  (That never hurts).