1995-12-07 - Re: Solution for US/Foreign Software?

Header Data

From: jim bell <jimbell@pacifier.com>
To: Bill Stewart <stewarts@ix.netcom.com>
Message Hash: bfe9815c2b4f24ef3cfda447347f6a83ae82d35ce324675d02f698084838a995
Message ID: <m0tNXBk-000930C@pacifier.com>
Reply To: N/A
UTC Datetime: 1995-12-07 04:19:17 UTC
Raw Date: Wed, 6 Dec 95 20:19:17 PST

Raw message

From: jim bell <jimbell@pacifier.com>
Date: Wed, 6 Dec 95 20:19:17 PST
To: Bill Stewart <stewarts@ix.netcom.com>
Subject: Re: Solution for US/Foreign Software?
Message-ID: <m0tNXBk-000930C@pacifier.com>
MIME-Version: 1.0
Content-Type: text/plain


At 03:36 PM 12/6/95 -0800, you wrote:
>>>>1.  Write a program with limited encryption (40 bit?), with the encryption
>>>>module in a file external to the  main program.
>>>>2.  Get export approval for this program.
>>>>3.  Write a module which replaces the encryption file, increasing key size
>>>>to whatever you REALLY wanted in the first place.  (128-bit IDEA, 2000-bit
>>>>PGP, etc.)
>>>>4.  Ship that new module with the old software to US customers.
>>>>Naturally, that new module will "leak," so anybody who buys the old
>
>Tim May replied
>>>"Crypto hooks," basically the scheme you are proposing, were thought of by
>>>the authorities and are not a bypass of the crypto export laws.
>
>I had interpreted the suggestion differently - rather than a system with 
>user-accessible crypto hooks, the manufacturer could ship a binary patch
>upgrade for US customers to install.  The internal design would presumably
>have crypto hooks (i.e. subroutine calls); they can't ban that.
>
>Of course, if you follow this strategy, get export approval for version 1.0,
>and ship the US-only patch as 1.1, getting export approval for version 2.0
>may be a shade more difficult...


And you get the prize because YOU guessed right! Sorry if I wasn't more clear.  

My premise:  Every program of length "n" bytes is simply an XOR away from
every OTHER program of length "n" bytes.  If one of those programs is the
export-allowed program and the other is the export-forbidden program, the
XOR file is the difference between them.   The "only" problem is to generate
the "XOR" file and get it out of the country.  The "getting it out of the
country" part is easy and will presumably happen because somebody not known
to the company does it.  At that point, the only problem is authentication:
This can be done easily using existing PGP digital signatures.

Obviously, only one copy of the XOR file needs to be exported, at least per
revision.  It is arguable that the export of that XOR file is illegal; so be
it.  It would be exported by an unknown person, using an unknown method, and
uploaded anonymously to a foreign server, all without the knowledge,
cooperation, or approval of the company.  






Thread