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

Header Data

From: Bill Stewart <stewarts@ix.netcom.com>
To: cypherpunks@toad.com
Message Hash: c2f8c2633e0e3eaa4eb7b7178ff7358060f8d6e131da18b6fe90f7cb510cc194
Message ID: <199512062336.PAA13979@ix6.ix.netcom.com>
Reply To: N/A
UTC Datetime: 1995-12-06 23:35:19 UTC
Raw Date: Wed, 6 Dec 95 15:35:19 PST

Raw message

From: Bill Stewart <stewarts@ix.netcom.com>
Date: Wed, 6 Dec 95 15:35:19 PST
To: cypherpunks@toad.com
Subject: Re: Solution for US/Foreign Software?
Message-ID: <199512062336.PAA13979@ix6.ix.netcom.com>
MIME-Version: 1.0
Content-Type: text/plain


>>>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...
#--
#				Thanks;  Bill
# Bill Stewart, Freelance Information Architect, stewarts@ix.netcom.com
# Phone +1-510-247-0663 Pager/Voicemail 1-408-787-1281

# Anybody notice that Microsoft's Wide Open Road ad has barbed-wire fences
# on both sides of the road?






Thread