🚀 go-pugleaf

I just joined this conversation, so forgive me if you've already
discussed this matter.

Apparently there ARE export controls on public domain information.
For example, the DES encryption algorithm is in the public domain,
but the export of DES encryption programs is strictly forbidden,
even to our friends in Great Britain.

The products that my company, Sun Microsystems, ship overseas do not
include des(1) or crypt(1). Crypt(1) has been a standard part of Unix
for many years and methods for breaking it have been known for years.
It provides minimal security. I was told that we are forbidden
by the State Department to export those from the U.S. even though
the algorithms are in the public domain.

I could almost understand an export restriction on a DES chip since
the fabrication of the chip itself might only be possible with
technology that is restricted or if the performance of the chip
exceeded that which is possible with existing "exportable" technology.
But a program is just another way to express the algorithm that
has already been published, albeit in a format that is machine
readable. Besides, any one of our customers can reprogram the
algorithm with the equipment that they are purchasing and with
information that they can find in any descent library (here or
abroad).

If the DES algorithm had been published in C or Pascal, then one
could imagine a situation in which we could export the source
code, but not the object code. If I were really ambitious and smart
enough then I could develop an expert system that could read the
NBS description of the DES algorithm and "compile" it directly
into 680X0 machine code. Then I would be confronted with a really
ludicrous situation: I could export the NBS document and my
expert system, but not the original binaries. I know, I know ... the
State Department would restrict the export of my "specification
compiler".

So what's the deal? Is there any logic or reason to the export 
restrictions? Or do I have my facts wrong?

	Kent Klinner
	Sun Microsystems