Most legal issues center around the problem of use and exportation of encryption software.
[Update: the Commerce Department now handles crypto export licenses, under the EAR, issued in December of 1996. These regulations, which are slightly more restrictive than the old ones, were enacted only days after Daniel Bernstein won his court case on the grounds that the old regulations violate the First Amendment. We are now awaiting a decision on the new regulations. The new regs do relax export restrictions in one respect: companies who agree to build in key escrow (for government access to data) features within 2 years can export 56-bit DES and code that relies on it.]
The sweep of the regulations is very broad: according to the text,
Category XIII-Auxiliary Military Equipment
includes...
(1) Cryptographic (including key management) systems, equipment, assemblies,
modules, integrated circuits, components or software with the capability of
maintaining secrecy or confidentiality of information or information systems,
except cryptographic equipment and software as follows:
(various exceptions for copy-protecting software, ATM card technology,
etc...)
(2) Cryptographic (including key management) systems, equipment, assemblies,
modules, integrated circuits, components or software which have the capability
of generating spreading or hopping codes for spread spectrum systems or
equipment.
(3) Cryptanalytic systems, equipment, assemblies, modules, integrated
circuits, components or software.
(4) Systems, equipment, assemblies, modules, integrated circuits, components
or software providing certified or certifiable multi-level security or user
isolation exceeding class B2 of the Trusted Computer System Evaluation Criteria
(TCSEC) and software to certify such systems, equipment or software.
[...]
Software is defined as follows:
Software includes but is not limited to the system functional design, logic flow, algorithms, application programs, operating systems and support software for design, implementation, test, operation, diagnosis and repair. A person who intends to export software only should, unless it is specifically enumerated in @ 121.1 (e.g., XIII(b)), apply for a technical data license pursuant to part 125 of this subchapter.
There is a 'personal use exception' which was just enacted in February 1996 but it is not useful for our present purposes. (However, it does answer Howie's question, 'Can you ever leave the country after learning this stuff?')
Among the wonderful case law which this has generated, is the Applied Cryptography Case, in which the book 'Applied Cryptography' was held to be exportable but the source code from the book, put onto floppy, was not.
Never mind that RSA, D-H, and every other algorithm I have mentioned up to now is freely available on the Internet from overseas; clearly those durn furners can't compile.
But now we have proof that they can't type.
Ah, but can they use a scanner? (MIT is following this up by trying to get permission to export PGP 2.6 source code in book form: -- in a nice ocr character set. See the book's web page to order a copy.
[Update: since then, PGP 5.0 has been released in 11 (?) volumes of OCR format with checksums. These volumes were then scanned in by non-U.S. citizens in the Netherlands, proofread, and then the source was made available for all. So far, the U.S. government has taken no action, and most folks believe that no action can be taken because the 'export' was accomplished through entirely legal means.]
Some companies have applied for and received permission to export implementations of algorithms such that other programs using these implementations can also be implemented. For example, ... with SHA-1.
Some algorithms are 'easy' to get permits for; that is, permits are routinely granted for their implementations. RC4 with 40-bit keys, MD5, and SHA-1 fall into this category.
How does this impact us directly? Netscape cannot release versions of their browser with encryption that supports 128-bit keys; 40 bits is the best they can get from the government. This means that if we want to provide browsers to our users on campus that have better than 'export-quality' strength encryption, we have to worry about who they are and who they might give a copy of the program to, and so on. The bottom line is that we can expect our user community to be using encryption that is not commercial strength, and that I wouldn't want to use to send *my* credit card number to a server.
[Update: a couple of months ago, Netscape announced that it had been given permission to export browsers with strong (128-bit) encryption for use only with special Verisign certificates which would be issued only to financial institutions abroad and to overseas branches of certain U.S. corporations.]
Our 'workaround', for the moment, is to point users at the location that they can get the Netscape 128-bit key browser, and to inform them about Mosaic-SSL and Lynx-SSL, available from outside of the U.S. and therefore free of such restrictions. Just *don't* export it back outside of the U.S. after retrieving it!
If you *do* feel the urge to export cryptography, get the Munitions T-shirt (which has the RSA algorithm in perl on it), and wear it on your way out through JFK. Just don't bring any floppy disks with you :-)