Developments in the _Junger_ suit

Now that Judge Patel has declared again in the _Bernstein_ case that
cryptographic software is entitled to the full protection of the First
Amendment, it is time for me to bring you up to date on some
developments on the Cleveland front.

To assist in the preparation of an amended complaint in my suit that,
like _Bernstein_, seeks to enjoin the enforcement of the export
regulations restricting publication of encryption software, my Legal
Attack Team on June 12 submitted several ``classification requests''
to the Department of Commerce in an effort to determine exactly what
is, and what is not, covered by the definition of encryption software 
set out in the Export Administration Regulations.

The Bureau of Export Aministration in the Department of Commerce
responded to these requests on or about July 4 and amplified their
response on or about August 7.  That response, though not generally
very helpful, did contain a number of surprises.  In particular, two
versions of a one-time pad encryption program using the XOR function
that I wrote in 8086 assembly language and machine code and a similar
OTP program written by Paul Leyland in one line of C, were classified
as EAR 99, which means that those programs are ``not subject to the
licensing restrictions for encryption software''.

No explanation was given as to why these programs implementing the one
unbreakable form of encryption are not classified as encryption
programs subject to ECCN 5D002.

More importantly, the classification requests included several pages
of HTML links to strong, unexportable encryption programs on several
FTP servers outside of the United States, but the Bureau of Export
Administration said that they were unable to classify that material,
and instead supplied us with an advisory opinion with respect to that
request saying:  ``Professor Junger's activity is not an export that
is subject to the Export Administration Regulations (EAR).''  The
Bureau subsequently amplified this response, saying:  ``While the use
of html links by a person might, in some applications, involve an
export . . . we reiterate that the activity described by your
submission is not an export activity that is subject to the EAR and
would also not constitute conduct prohibited by Section 744.9 of the
EAR.'' 

The Bureau did, however, classify several programs that we submitted,
including one written by me in C that implements several different
encryption algorithms and Adam Back's RSA program in three lines of
Perl (which is available at <http:/www.dcs.ex.ac.uk>), as being
encryption programs that are subject to the export restriction of the
EAR.

The most significant part of the Bureau's response, however, was their
professed inability to classify one way or the other all programs
implementing certain specified encryption algorithms such as, for
example, OTP programs that XOR the bytes comprising the message with
the bytes in a one-time pad.  The Bureau said as to this request:
``BXA cannot provide a single classification opinion for any
encryption product that `implemements' a certain algorithm''.

Due to the kindness of John Young, our requests for classification and
BXA's responses will be available shortly at <http://www.jya.com/>.
The links to cryptographic programs on FTP sites outside the United
States are already available at 
<http://samsara.law.cwru.edu/links/cryptolinks.html>.

Stay tuned for further announcements once this labor day weekend is
past.

--
Peter D. Junger--Case Western Reserve University Law School--Cleveland, OH
 EMAIL: junger@samsara.law.cwru.edu    URL:  http://samsara.law.cwru.edu   
     NOTE: junger@pdj2-ra.f-remote.cwru.edu no longer exists

Peter Junger <junger@samsara.law.cwru.edu> writes:
> [...]
> The Bureau did, however, classify several programs that we submitted,
> including one written by me in C that implements several different
> encryption algorithms and Adam Back's RSA program in three lines of
> Perl (which is available at <http:/www.dcs.ex.ac.uk>), as being
> encryption programs that are subject to the export restriction of the
> EAR.

Yay!  It's officially non-exportable.  It would be kind of fun to
observe a lawsuit built around someone in the US using this as a .sig:

: Have *you* exported RSA today? --> http://www.dcs.ex.ac.uk/~aba/rsa/
: 
: print pack"C*",split/\D+/,`echo "16iII*o\U@{$/=$z;[(pop,pop,unpack"H*",<>
: )]}\EsMsKsN0[lN*1lK[d2%Sa2/d0<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<J]dsJxp"|dc`
 
Perhaps they should round up all those who have used it in the past as
a .sig and lock them up.

> BXA are quoted as writing:
> : While the use of html links by a person might, in some applications,
> : involve an export . . .

I must admit to being very curious as to how html links can be an
export.

Is this an export?

	RSA .sig

Is this?

	PGP 5.0i

(guessing URL).

This one might be fun also, but still I can't see that it's an export:

	<IMG SRC="http://www.dcs.ex.ac.uk/~aba/shirt/rsa.gif">

(it's an inline image of the RSA .sig).

> The most significant part of the Bureau's response, however, was their
> professed inability to classify one way or the other all programs
> implementing certain specified encryption algorithms such as, for
> example, OTP programs that XOR the bytes comprising the message with
> the bytes in a one-time pad.  

Weird so this is exportable (otp.c):

main(i,c)int*c;{for(c=fopen(c[1],"r");i=~getchar();putchar(getc(c)^~i));}

Here's a perl one too btw:

open P,shift;read(P,$p,length),print $_^$p while<>

Adam
-- 
Have *you* exported RSA today? --> http://www.dcs.ex.ac.uk/~aba/rsa/

print pack"C*",split/\D+/,`echo "16iII*o\U@{$/=$z;[(pop,pop,unpack"H*",<>
)]}\EsMsKsN0[lN*1lK[d2%Sa2/d0<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<J]dsJxp"|dc`