From: jimbell@pacifier.com (jim bell)
To: tcmay@got.net (Timothy C. May)
Message Hash: fd006cfd275da618509b378b46fb45a473ce20b91fcc0e1e54fb7ecc59d08a9e
Message ID: <m0tNOTZ-0008yNC@pacifier.com>
Reply To: N/A
UTC Datetime: 1995-12-06 18:57:43 UTC
Raw Date: Wed, 6 Dec 95 10:57:43 PST
From: jimbell@pacifier.com (jim bell)
Date: Wed, 6 Dec 95 10:57:43 PST
To: tcmay@got.net (Timothy C. May)
Subject: Re: Solution for US/Foreign Software?
Message-ID: <m0tNOTZ-0008yNC@pacifier.com>
MIME-Version: 1.0
Content-Type: text/plain
>At 8:06 AM 12/6/95, jim bell wrote:
>
>>>"Crypto hooks," basically the scheme you are proposing, were thought of by
>>>the authorities and are not a bypass of the crypto export laws.
>>>--Tim May
>>
>>
>>I'm not saying they are a "bypass" of the laws. Rather, I'm saying that
>>if the goal is to:
>>
>>1. Let companies like Netscape make foreign sales.
>>
>>2. Still comply with the letter of the law.
>>
>
>And I'm saying that your proposal does NOT comply with the letter of the
>law. There's no point in arguing this, as the facts are clear. Consult the
>ITARs and the previous discussions here and elsewhere on the practice of
>leaving "hooks" that crypto modules can later be attached to.
NO! You didn't read my commentary carefully enough. These "hooks" (your words) will, in effect, already be connected to encryption software weak enough to make NSA happy. You know, 40 bit keys or something like that.
But instead of being in one large file, embedded into a program, it'll be TWO files. Simple programming change. Everything that implements/defines/limits the encryption to 40 bits will be in the smaller file.
This really isn't a "hook," it's an internal connection between two portions of the same program. (actually, it wouldn't need to be in two separate files; a file which implements a patch for the first file would work great.)
It'll be exportable, because its key size is "acceptable." At the time the export license is requested, the replacement module to increase key size probably won't even exist, in order to avoid giving the USG an excuse to deny the export license. After the license is obtained, the replacement module is written and shipped to domestic users.
I fully realize the USG won't "like" this kind of thing. But if they are trying to take the position that certain kinds of encryption software CAN be exported, and some can't, they're going to have to approve SOME programs for export, using criteria which at least pretend to be objective.
In view of the nearly limitless possibility of patches, how would YOU distinguish between programs?
Return to December 1995
Return to “jimbell@pacifier.com (jim bell)”
1995-12-06 (Wed, 6 Dec 95 10:57:43 PST) - Re: Solution for US/Foreign Software? - jimbell@pacifier.com (jim bell)