Re: Solution for US/Foreign Software?
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.
It takes more than one or two people to coordinate an international effort. Once more than a few people know about it, it becomes "company policy" or "corporate objective", in which case, the NSA/DoS will eventually figure it out and start levying heavy fines and jailing the individuals.
You miss the point! There will be no "international effort"! Here are the steps: 1. Write a program limited to keysize, carefully constructed to isolate those portions of the program which define key size, GAKedness, etc. 2. Get it export approved. Export it. THEN 3. Announce that a "US-only" version of the same program is being released, and include the minimal component which replaces the limited software. Release it, only in the US of course!
The main point is that there is no such thing as the "letter of the law". What they enforce is much broader than that, and how they enforce it is much more subtle than clear-cut criminal prosecution. Therefore, you cannot just use literal loop holes just because it's not clear, because the law they are enforcing is not clear either.
The system I describe doesn't even violate the spirit of the rules. If anything, it bends over backward to implement a foreign version of the software which ALREADY is export-approved at the time it was, um, upgraded. True, it's possible to sneak the extra component out of the country, but hey, it's also possible to sneak an entirely new program out of the country. I'm not suggesting that the company who writes the component takes it out, it'll happen regardless. If the order of the versions was reversed, the USG might complain that the export version was "too similar" to the domestic version. That's why you wait for the export approval before you write the domestic version.
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
jim bell writes, carefully avoiding the "Return" key:
1. Write a program limited to keysize ... 2. Get it export approved. Export it.
If you do step 1, then step 2 is impossible. If your application is constructed such that a non-export-approvable cryptosystem can be dropped on top, then you will not get export approval. (I know this from our direct experience here.) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | Nobody's going to listen to you if you just | Mike McNally (m5@tivoli.com) | | stand there and flap your arms like a fish. | Tivoli Systems, Austin TX | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
I don't know the US-Export regulations very well, so please allow a quick one: Maybe a legal way around the keysize-regulation would be: Many US companies have subsidiaries <sp?> outside the US. Some of them are leaded by non-US-citizens. 1) The U.S.-company engineers a software with strong (but legal) crypto for use inside the U.S. The program is sold in the U.S. At the same time the company exports the sourcecode of the program *without* any crypto at all to their subsidiaries. (should be legal) 2) one or more of the subsidiaries include "self-engineered" crypto-routines into the program-"hull" they received from inside the U.S. This program is sold in th subsidiaries countries (Europe etc.) Two things have to be assured: - Both crypto-routines have to be compatible - No U.S.-citizens must be involved in the engineering of the subsidiaries crypto-routines. Any comments? ohuf.
participants (4)
-
dreschs@mpd.tandem.com -
jimbell@pacifier.com -
m5@dev.tivoli.com -
Oliver Huf