[John Gilmore <gnu@toad.com>] Re: crypto networking code

["Darren/Torin/Who Ever..." <torin@daft.com>]

-----BEGIN PGP SIGNED MESSAGE-----

I thought this to be of import to the Debian project.  Note especially
what he says about the kernel tar file being assembled in a free country
(such as Finland rather than the US) and that CDROM and FTP distributors
in non-free countries (such as the US) would either have to
geographically limit their dist or rip out code pieces.

I'm strongly opposed the the idiotic crypto export laws in the U.S.  All
the while, I think this is something that we need to pay attention to.

Darren
- -- 
<torin@daft.com> <http://www.daft.com/~torin> <torin@debian.org> <torin@io.com>
Darren Stalder/2608 Second Ave, @282/Seattle, WA 98121-1212/USA/+1-800-921-4996
@ Do you have your clothes on? I probably don't. Take yours off. Feel better. @
@ Sysadmin, webweaver, postmaster for hire.  C/Perl/CGI programmer and tutor. @

- ------- Start of forwarded message -------
Message-Id: <199611061303.FAA02951@toad.com>
To: Nathan Bryant <nathan@burgessinc.com>
cc: Linux Kernel <linux-kernel@vger.rutgers.edu>, John Gilmore <gnu@toad.com>
Subject: Re: crypto networking code
Date: 	Wed, 06 Nov 1996 05:02:51 -0800
From: John Gilmore <gnu@toad.com>

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
	   http://www.eff.org/pub/Legal/Cases/Bernstein_v_DoS/
	*  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 http://prometheus.hol.gr/~ji/ipsec-0.2.tar.gz
	*  It's very alpha test, still.
	*  Details on the project are at http://www.cygnus.com/~gnu/swan.html
	*  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, ji@hol.gr).
	*  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
	   cryptography.
	*  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'
	   machines.
	*  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 http://cwis.kub.nl/~frw/people/koops/lawsurvy.htm
	*  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
	gnu@toad.com
	http://www.cygnus.com/~gnu		(my web page)
	http://www.cygnus.com/~gnu/swan.html	(this project's page)
	http://www.cygnus.com/~gnu/export.html	(crypto export web page)

- ------- End of forwarded message -------

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface

iQCVAwUBMoIS844wrq++1Ls5AQECqAP+M8IHlg/GNKCmX9UndGUWVJDRwSAekmkR
7DONciH5n/Wk3PmPsgmhoctWDF5ole249cXjXHo3SM5bANuzeo6QyQhfSPnS4rq8
LoRf8vdPiw+chMx0AMd6J4wbtnCMkPULX31y3YCRm51xstEwAX/uk4ckl0nrJeu6
Ouq6fRwksZM=
=yAPa
-----END PGP SIGNATURE-----

--
Please respect the confidentiality of material on the debian-private list.
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-private-REQUEST@lists.debian.org . Trouble? e-mail to Bruce@Pixar.com