[MUD-Dev] Re: Modular MUD

[Caliban Tiresias Darklock]

On 01:03 PM 8/31/98 -0700, I personally witnessed quzah jumping up to say=
:
>
>What's the big deal with encryption not being able to be exported? Does
>the government think noone outside the US is smart enought to think up
>some good encryption on their own?

I've done some research in the matter... whether this practice is right o=
r
wrong is *definitely* off topic, but I'd personally figure that the
information about the practice itself isn't.=20

Encryption technology is classified as primarily military in nature, and
therefore regulated under "Category XIII-Auxiliary Military Equipment" of
the Munitions List, which covers Information Security Systems and
equipment, cryptographic devices, software and components specifically
designed or modified therefore -- *except* encryption used to prevent
software piracy, to maintain the integrity of data flow, in the processin=
g
of monetary transactions (such as ATM machines and point of sale
terminals), to protect passwords and PIN codes (provided that the
encryption technology does not also allow the customer to encrypt files o=
r
text messages), and encryption of signals for use in broadcasting.=20

Before you party, however, the above *do* fall under the Commerce
Department=92s dual-use control regime which is controlled by the DOC=92s
Bureau of Export Administration=92s Office of Strategic Trade and Foreign
Policy Controls based on the Export Administration Act (EAA), the Export
Administration Regulations (EAR) and the Commerce Control List (CCL). In
order to determine which category your software falls under (munitions or
export controls), you send your software to... guess who?=20


The National Security Agency. The NSA "... performs the technical review
that determines, for national security reasons, (1) if a product with
encryption capabilities is a munitions item or a Commerce List item and (=
2)
which munitions items with encryption capabilities may be exported. The
Department of State examines the NSA determination for consistency with
prior NSA determinations and may add export restrictions for foreign poli=
cy
reasons-- e.g., all exports to certain countries may be banned for a time
period... The detailed criteria for these decisions are generally
classified. However, vendors exporting these items can learn some of the
general criteria through prior export approvals or denials they have
received." (General Accounting Office, "FBI Advanced Communications
Technologies Pose Wiretapping Challenges", 1993c.)

The NSA also advises companies as to whether products in development woul=
d
be munitions items and whether they would be exportable, according to Sta=
te
Department representatives.=20

So, in a nutshell: When you create a program that uses encryption, that
program must (evidently) pass three reviews. First, the NSA determines
whether your encryption is regulated as munitions. Second, either the NSA
or the Commerce Department determines whether your software is of
sufficient strength to merit export control. And third, they provide you
with a license agreement which must be included with the software, such a=
s
the following from PGP 2.6.2: "PGP is export restricted by the Office of
Export Administration, United States Department of Commerce and the Offic=
es
of Defense Trade Controls and Munitions Control, United States Department
of State. PGP cannot be exported or reexported, directly or indirectly, (=
a)
without all export or reexport licenses and governmental approvals requir=
ed
by any applicable laws, or (b) in violation of any prohibition against th=
e
export or reexport of any part of PGP. The Government may take the positi=
on
that the freeware PGP versions are also subject to those controls."

What it looks like to me is that *whatever* you do, the encryption proces=
s
must be reviewed and verified by the NSA and/or the Commerce Department. =
I
would suspect that there are at least *some* established exportable
encryption methods, but they seem reasonably hard to find.=20

The obvious solution is to use something widely available as a plug-in. A
developer in the UK has written a set of Windows DLLs which implement DES=
,
IDEA, MD5, and MDC ("a cipher based on the strong cryptographic propertie=
s
of MD5"). This set of DLLs is available from many servers outside the US,
but must be provided for at compile time, so whatever you use them with h=
as
to be specifically targeted at them and recompiled by the end user. For
client software, this isn't really reasonable, and since it's Windows I
think it may not be what most list readers are looking for.

Here's the weird part. While encryption *software* is a munition,
encryption *algorithms* are speech -- so while you cannot export source
code for IDEA, you can quite freely export instructions on how to write
such source code. Bruce Schneier's "Applied Cryptography" hit up against
this snafu; while the book was exportable, the government flatly refused
under any circumstances to allow them to bundle a source code disk with i=
t.=20

This lends itself to certain possibilities. You *could* create software
which DOES NOT ENCRYPT -- but which allows encryption when a user-supplie=
d
library is available. Ideally, this would be done at runtime. You could
provide an "example" description which specified your proposed standards
for the encryption library, and then hope that someone out there wrote
one... or you could coordinate (as has been suggested) with another
developer outside the US, who would develop the encryption library prior =
to
release and then just have it available for download on his internet site.
Alternately, you could use an already-available dynamic library from a
non-US source.


-----------------------------------------------------------------------
Caliban Tiresias Darklock <caliban at darklock.com>   | "I'm not sorry or=20
Darklock Communications <http://www.darklock.com/> |  ashamed of who I=20
PGP Key AD21EE50 at <http://pgp5.ai.mit.edu/~bal/> |  really am."     =20
FREE KEVIN MITNICK! <http://www.kevinmitnick.com/> |  - Charles Manson=20