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.