Re: crypto networking code

John Gilmore (
Wed, 06 Nov 1996 05:02:51 -0800

Nathan cc'd me on part of this discussion, and I've finally followed the
whole thread in linux-kernel. There was a lot of misinformation in there.
Here's the situation from my point of view:

US crypto laws and regulations:

* US law & regulations are very imprecise and hard to figure out
* NSA likes it that way because it discourages people from trying
* I've spent ten years understanding it though...

* There are no restrictions on the use of crypto in the US
* There are no restrictions on sending encrypted data inside the US
or across the border (in either direction)
* There are no restrictions on the import of crypto code into the US
* There are three kinds of restrictions on export: on "defense
articles" (hardware and crypto software), "technical data"
(documentation, etc, directly related to a defense article), and
"defense services" (doing something that helps someone build a
defense article).

Regarding export of crypto software ("defense article") from the US:

* If the crypto is for authentication, then it goes by loose rules
(Commerce Dept).
* If the crypto uses RC2 or RC4 with 40-bit keys, and uses no more
than 512-bit RSA keys in the keying, it goes by loose rules.
* Note that this requires both the key length AND the algorithms;
not all 40-bit algorithms qualify.
* GPL, PD, or UCB-copyright code published by FTP or Web is "public
domain" (they misuse the term) under the loose rules
* Loose rules permit "public domain" crypto code to be exported
without any paperwork or restrictions (except to six or seven
"terrorist" countries to which you can't export *anything*).

* If your crypto doesn't go by loose rules, then you can't publish it.
* They want you to identify every recipient (in advance) and let them
OK or reject each one.
* Export permission for 3DES (triple-des) is reportedly arbitrarily
denied without any cause or reason. It's likely to be political,
since NSA is trying to convince the American Bankers Association
to adopt some GAK (government access to keys) scheme instead of
3DES for banking networks and ATM machines.

* "Technical data" is not export-controlled if it is published or
otherwise available to the public, only if it is unpublished.
* Linux and its documentation are all published. To the extent that
any of it is "technical data" as opposed to "defense article",
it's not export controlled.

* "Defense services" includes for example somepenguin in the US
typing the commands on a Finnish machine that would cause it to
create or improve crypto software. This is illegal.

* There are lots of other rules and implications of rules; I'm only
covering what's relevant to Linux and IPSEC.
* VP Gore announced in October that they'll try to rearrange all
the regulations (while making no substantive change) next year.
He's still pushing Clipper, now known as Trusted Third Parties
or Key Recovery. Some companies appear to have agreed with him,
notably IBM.
* I'm behind a lawsuit that's trying to have a US Federal court
declare the export laws unconstitutional, at least as applied
to international distribution of crypto source code. See
* There are two other similar lawsuits pending, by Karn and Junger.

As for the Linux IPSEC implementation:

* It's all been completely written outside the US.
* It's available from
* It's very alpha test, still.
* Details on the project are at
* I catalyzed this implementation to occur, by encouragement.
I'm promoting the idea, e.g. in this month's Wired and Unix Review.
And in this message. I'm doing some of the user-level programming
(DNSSEC) because it's authentication and therefore exportable.
* The rest is funded by a European philanthropist and coded by a
European programmer (John Ioannidis,
* The intent is for it to become part of the mainstream Linux kernel
source and binary release (compiled in, or as a module).
* Linux, being the only major OS maintained outside the US, has a
major competitive advantage by being able to incorporate strong
* I checked with Linus in advance and got his approval.
* My motivation is to spread this technology far and wide before
it becomes illegal, and in so doing, perhaps prevent such bogus
laws from ever being passed. We are literally in a race between
our ability to build and deploy technology, and their ability to
build and deploy laws and treaties. Neither side is likely to
back down or wise up until it has definitively lost the race.
* To spread the technology most widely, it helps to have it in
the main distribution rather than in a separate distribution.
* In particular this makes it more likely to end up on CDROMs.
* A large part of its intended market is in encrypting-gateway
boxes that would automagically encrypt the traffic for an entire
LAN before putting it on the Internet. This has the advantage
of not having to change the software or hardware on the end-users'
* It's great to see Linux moving 83 Mbits/sec on a 100Mbit/sec
Ethernet (close to the theoretical max). With hardware
crypto boards I hope we can eventually crypto-gateway at
almost similar speeds.
* EFF is backing me in this initiative, though they haven't done
too much yet because the software is only now coming ready.

A Linux kernel with IPSEC crypto would have these effects:

* This part of the kernel would have to continue to be maintained
in a free country (like Finland, unlike US)
* Final assembly of a kernel tar file for worldwide distribution
would have to occur in a free country.

* The resulting kernel could be imported into almost all countries.
* The kernel could not be exported from some industrial countries
such as the US and Germany.
* The kernel could be possessed and used in all but a few terrible
countries (like France).

* The Internet would become more private and secure for all those
who used this kernel and its associated daemon.
* The Linux community would master the intricacies of both crypto
laws and crypto technology, and be well positioned to build and
ship and support high quality encryption products of all kinds,
not just IPSEC and IPv6. For example, ssh, SSLeay, etc
would be easy to add to Linux distributions once distributors
figure the export issues.

* CDROM distributors in free countries would have no problems.
* CDROM distributors in unfree countries would have to either limit
their distribution to their home country, rip the crypto
out of their distribution, or make two distributions (one
real, one gutted).
* FTP distributors in free countries would have no problems.
* FTP distributors in unfree countries would have to rip up or
geographically limit their distribution (like CDROM distributors).
* This would encourage distribution from free countries; what a shame.

* For country-by-country details, see Bert-Jaap Koops' Crypto
Law Survey at
* Countries which simply follow COCOM rules permit the
export of mass-market and public domain crypto software unless it
is designed for military use. E.g. UK, Italy, Austria, Sweden.
* Linux is both mass-market and "public domain" (by their definition),
and not military, so it qualifies for export under COCOM; these
countries are "free" as I have been using the term.

Hmm, did I leave anything out? Oh yeah:

* I'm not sure what the effect of Linus moving out of a free
country will have on all this. I hope we can preserve most of
the benefits of Linux being maintained in a free country.
* Crypto laws and regs change quickly. Check with a real lawyer
when it matters. Send updates to the Law Survey.
* The US is quietly lobbying any and all governments to clamp down on
crypto. They see it as providing the US a good excuse for doing
so. White House spokespeople have already said
"See! We were right! France and Russia are doing it too..."
They slipped something into Belgium's laws without anyone noticing.
* Keep an eye on your own country's crypto politics. Talk to
ministers, legislators, and the press. Tell them how you feel,
and let them call on you for expertise when changes are in the air.
Most of them have never faced the issue and just need education.

Thanks for wading through all this...

John Gilmore (my web page) (this project's page) (crypto export web page)