1997-09-16 - Re: The great GAK crack (making GAK economically impossible)

Header Data

From: nospam-seesignature@ceddec.com
To: amp@pobox.com
Message Hash: aefcdbd0f94e6884a8bb6640a13f6c9cda595a286bee662c4419bcb1182e6819
Message ID: <97Sep16.183447edt.32258@brickwall.ceddec.com>
Reply To: <Chameleon.874375612.amp@ampugh.mcit.com>
UTC Datetime: 1997-09-16 22:51:52 UTC
Raw Date: Wed, 17 Sep 1997 06:51:52 +0800

Raw message

From: nospam-seesignature@ceddec.com
Date: Wed, 17 Sep 1997 06:51:52 +0800
To: amp@pobox.com
Subject: Re: The great GAK crack (making GAK economically impossible)
In-Reply-To: <Chameleon.874375612.amp@ampugh.mcit.com>
Message-ID: <97Sep16.183447edt.32258@brickwall.ceddec.com>
MIME-Version: 1.0
Content-Type: text/plain



On Mon, 15 Sep 1997 amp@pobox.com wrote:

>   From: nospam-seesignature@ceddec.com
> > 
> > My test software uses a loop that generates a new pair every few seconds
> > on a pentium (and found some very obscure bugs).  I would be required to
> > send all those to the gak.gov.  If they really want them...
>  
> which bugs would those be? key generation is pretty critical. i'd be 
> interested in any strange results you've found.

None specifically in PGP 5.0 or 2.6.2 itself, but I did find the
limitation of 13 bits on compression, that the MPI encoding would not
accept integers with leading zero bytes, but would with leading zero bits
(this was one obscure bug since I had to randomly generate a value much
less than the modulus), and the fact that an ElGamal key value causes
segfaults. I was implementing a library and found where my code and real
PGP didn't get along.  Some combinations aren't generated by PGP, and some
aren't accepted. 

--- reply to tzeruch - at - ceddec - dot - com ---






Thread