1994-12-17 - Re: Thoughts on 15 day CJ crypto

Header Data

From: eric@remailer.net (Eric Hughes)
To: cypherpunks@toad.com
Message Hash: 3eadb104c629332db98c7b17ac18811b104bb3c5fe797a9c0af503cb370fef80
Message ID: <199412172340.PAA11144@largo.remailer.net>
Reply To: <199412172058.MAA13081@jobe.shell.portal.com>
UTC Datetime: 1994-12-17 22:42:55 UTC
Raw Date: Sat, 17 Dec 94 14:42:55 PST

Raw message

From: eric@remailer.net (Eric Hughes)
Date: Sat, 17 Dec 94 14:42:55 PST
To: cypherpunks@toad.com
Subject: Re: Thoughts on 15 day CJ crypto
In-Reply-To: <199412172058.MAA13081@jobe.shell.portal.com>
Message-ID: <199412172340.PAA11144@largo.remailer.net>
MIME-Version: 1.0
Content-Type: text/plain


   From: Hal <hfinney@shell.portal.com>

   Maybe it would be wise when using limited-length
   session keys to use larger encryption exponents just to confound an
   exhaustive search of the session key space.  

It would, but remember that you're generally going to be generating
those keys with the application that will be using them eventually.
One could write a spoofer, perhaps, to generate you're own keys, but
most people won't be using it.

   I think it is surprising
   if there is no limitation on encryption exponent size for these
   exportable key systems, assuming that is the strategy the government is
   using.

Consider the position from the viewpoint of the NSA.  Suppose that the
hypothesis is correct, and session keys encrypted with short exponents
are used to verify candidates.  You haven't told anybody this is the
reason for the particulars of the restrictions.

So, do you, the NSA, write the restriction into the regulation?  Or do
you rely on the fact that the developer will optimize public keys for
speed?

The first strategy reveals tactics.  The second carries some risk.

Eric





Thread