Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!allegra!alice!research!dmr
From: dmr@research.UUCP
Newsgroups: net.crypt
Subject: export controls
Message-ID: <1041@research.UUCP>
Date: Mon, 17-Sep-84 01:15:46 EDT
Article-I.D.: research.1041
Posted: Mon Sep 17 01:15:46 1984
Date-Received: Tue, 25-Sep-84 04:01:34 EDT
Lines: 52

As has been said, there is indeed a special "International Edition"
of System V that differs from the ordinary system in that it
lacks the crypt command, the encrypting features of ed and vi, and the
encrypt entry of crypt (3).  The crypt entry, which is used for
passwords, is there, as is the underlying DES algorithm.

Here's how it happened.

About a year ago, I got mail from Armando Stettner saying basically,
"Do you know of any problems with exporting crypt?  Our lawyers
[at DEC] are worried about it."  I replied that such worries were
utterly unfounded for a variety of sensible reasons.

Now, as it has turned out, DEC was very justified in worrying about
export controls in general; they have recently been fined (I think) $500,000
for the Vaxen that almost got sent to Russia.  I conjecture that
the earliest stages of this or a similar incident were already in progress
and they were trying to be extra careful when they learned about crypt.

At any rate, the DEC lawyers communicated their fears to AT&T,
and the AT&T lawyers, equally cautious, sought government advice.

The problem, you see, is that cryptographic materials are under export
control.  There is a thing called the Munitions Control Board that worries
not only about machine guns going to Libya, but also about the crypt
command going to England.  In practice, the enforcement is done by the
Commerce department.

AT&T had a meeting with Commerce, the MCB, and NSA.  The upshot was
that they decided it would be simplest all around just not to export
the crypt command.  The gov't would almost certainly have granted
the license, but (probably wisely) AT&T decided it wasn't worth
the hassle.

In technical terms, the situation is ludicrous. The encrypt subroutine
is distinguished mainly by the excruciating care I took to make it
an exact transcription of the algorithm published in the Federal Register,
and by its slowness.   NBS, the caretaker of DES standardization,
is explicit that software implementations cannot be certified, so in that
sense encrypt is not "real" DES.  The underlying subroutine is still
there, only the simple command that uses it is missing.  So there is
actually nothing to protect, and even if there were, it's not protected.
Nevertheless, in the present situation we officially don't need
an export license, whereas with the crypt command we would.

In political terms, AT&T probably could have done better.  Conservative
and careful, they called a big meeting at which no one could possibly
have put forward anything but official positions about encryption
programs.  Private checking with well-placed people in the appropriate
agencies might well have done the job.  But who knows?

		Dennis Ritchie