1996-06-04 - Re: Java Crypto API questions

Header Data

From: shamrock@netcom.com (Lucky Green)
To: jim bell <jimbell@pacifier.com>
Message Hash: 4fc777f21bd8c8956da7a256f485c191532107440f4c57b8af886d2074b9866d
Message ID: <v02120d15add98b67e218@[192.0.2.1]>
Reply To: N/A
UTC Datetime: 1996-06-04 10:03:15 UTC
Raw Date: Tue, 4 Jun 1996 18:03:15 +0800

Raw message

From: shamrock@netcom.com (Lucky Green)
Date: Tue, 4 Jun 1996 18:03:15 +0800
To: jim bell <jimbell@pacifier.com>
Subject: Re: Java Crypto API questions
Message-ID: <v02120d15add98b67e218@[192.0.2.1]>
MIME-Version: 1.0
Content-Type: text/plain


At 16:22 6/3/96, jim bell wrote:

>A signature is just that:  A signature.  It doesn't encrypt or decrypt.  It
>doesn't even ALLOW the system it's in to encrypt or decrypt, because there
>are numerous encryption programs written that have no need for such a
>signature.  If no program existed which _used_ that signature, nobody would
>think twice about exporting it.
>
>The fact is, it is LEGAL to import encryption code into the US.  It is LEGAL
>to generate an hash of that code, and it is LEGAL to export that hash.  To
>believe otherwise is to broadly expand the scope of export laws far beyond
>what they were intended to mean.

First, the ITAR are not laws, but regulations. Second, there are many that
believe that applying ITAR to crypto software is already expanding the
scope of the regulations far beyond what they were intended to mean.

Let us not forget that the ITAR were written to prevent the proliferation
of military technology. Applying them to mass market crypto software does
not aid this original goal in any way. At one point, the existing ITAR
began to be used to further a cause utterly unrelated to their original
intend: limiting the domestic market penetration of strong crypto systems.


Disclaimer: My opinions are my own, not those of my employer.

-- Lucky Green <mailto:shamrock@netcom.com>
   PGP encrypted mail preferred.







Thread