From: jim bell <jimbell@pacifier.com>
Date: Thu, 7 Dec 95 12:03:32 PST
To: dreschs@mpd.tandem.com (Sten Drescher)
Subject: Re: Solution for US/Foreign Software?
Message-ID: <m0tNm1C-00092KC@pacifier.com>
MIME-Version: 1.0
Content-Type: text/plain


At 10:26 AM 12/7/95 -0600, you wrote:
>jimbell@pacifier.com (jim bell) said:
>
>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?

Okay, that was basically what I was suggesting.  A full binary difference
file wouldn't even need to have any information about the internals of the
program anyway.

Basically, what needs to be achieved is a way to allow the software
manufacturer to sell an approved product outside the country, but allow the
foreign buyer to (easily) convert it into a GOOD encryption product.  Once
that works, laws against the export of encryption are meaningless.  In fact,
the legally-exported program obviously wouldn't even need to HAVE encryption
in it at all, so it won't fall under ITAR classification, and thus won't
need any kind of export license.