From: dreschs@mpd.tandem.com (Sten Drescher)
Date: Thu, 7 Dec 95 08:23:10 PST
To: cypherpunks@toad.com
Subject: Re: Solution for US/Foreign Software?
In-Reply-To: <m0tNR0t-00093sC@pacifier.com>
Message-ID: <5568fsj0wg.fsf@galil.austnsc.tandem.com>
MIME-Version: 1.0
Content-Type: text/plain


jimbell@pacifier.com (jim bell) said:

jb> You miss the point!  There will be no "international effort"!  Here
jb> are the steps:

jb> 1.  Write a program limited to keysize, carefully constructed to
jb> isolate those portions of the program which define key size,
jb> GAKedness, etc.

jb> 2.  Get it export approved.  Export it.

jb> THEN

jb> 3.  Announce that a "US-only" version of the same program is being
jb> released, and include the minimal component which replaces the
jb> limited software.  Release it, only in the US of course!

	As has been pointed out, this would prolly doom geting export
approval for version 2.0.  However, let's keep the developer/publisher
out of the loop.  How about someone developing a 'binary diff', using
the functionality of nm to find subroutine entry points, and then doing
the binary diff from those starting points?  Presumably, for most of the
program the diff would mostly be changed entry points, with the bulk of
diff being the crypto module.  Then the bdiff gets exported, and
bpatch-ed into the export binary.  Of course, this wouldn't work if they
strip the binary, but who is going to force them to do that?

-- 
#include <disclaimer.h>				/* Sten Drescher */
To get my PGP public key, send me email with your public key and
	Subject: PGP key exchange
Key fingerprint =  90 5F 1D FD A6 7C 84 5E  A9 D3 90 16 B2 44 C4 F3