From: Hal <hfinney@shell.portal.com>
Date: Wed, 3 Apr 1996 18:59:47 +0800
To: cypherpunks@toad.com
Subject: Re:  software with "hooks" for crypto
Message-ID: <199604030147.RAA10970@jobe.shell.portal.com>
MIME-Version: 1.0
Content-Type: text/plain


From: me@muddcs.cs.hmc.edu (Michael Elkins)
> I've written a Unix e-mail client which contains support for PGP/MIME and
> also a front end for mixmaster.  Right now I basically reap all the "bad"
> code before I distribute it (at _least_ 50% of my testers are outside the
> US).  However, this has been annoying for those users because they want
> to be able to use the PGP support (so do I!).  So, what I'm wondering is
> what the laws are regarding snail-mailing source code to these people.
> The actually pgp/remailer stuff isn't more than a few pages of code, which
> could easily be transcribed or scanned in with OCR software.  Would I
> have to get a "license for export" in order to send the code outside the
> US?

Let me first point out that this procedure is not as easy as it sounds.
Phil Karn has an interesting description of what happened when he
actually tried to do this, as part of his suit to try to export the
Applied Cryptography source code on disk.  It is at <URL:
http://www.qualcomm.com/people/pkarn/export/karndecl.html >.  This is
something that people have talked about for a long time, and it is
interesting to see what happened when he tried it:

   5. I began by first photocopying, on a standard office photocopier,
   the 18 pages containing the Triple DES source code listing from Part V
   of the Book. This took about 5 minutes. Second, I scanned in the 18
   sheets on a Macintosh Quadra 610 computer system equipped with an HP
   ScanJet II flatbed scanner and Omnipage Professional optical character
   recognition (OCR) software. The computer, scanner, and software are
   all readily available through normal consumer computer supply
   channels. The total scanning process took about one and a half hours.
   About an hour of this time was spent learning to use the scanning
   system and conducting trial runs, as I had only used it briefly some
   time ago. The actual scan of the 18 pages took about 15-20 minutes.
   Third, I transferred the resulting machine-readable file from the
   Macintosh to my own personal computer and brought it up under GNU
   EMACS, a popular and widely available text editing program that I have
   used for many years. In EMACS I compared, by eye, the scanned file
   displayed on my screen against the printed listing in the Book. I
   began correcting the scanner's many errors, such as mistaking the
   digit '0' for the letter 'O' or mistaking the vertical bar '|' for the
   letter 'I'.
   
   6. After manually correcting those errors noticed through visual
   comparison with the Book, I invoked the "C" language compiler on the
   (partially) corrected file. The compiler immediately pointed out
   additional errors I had overlooked in my visual inspection so I could
   also correct them by reference to the Book. I also noticed several
   errors in the listing printed in the Book. However, the programmer's
   intentions were obvious from the context of each error and were easily
   fixed. About fifty minutes later, I successfully compiled the file
   without error.
   
   7. The fourth step was to write a small test program to execute the
   DES code with the test vectors given at the end of the source code
   listing. This trivial program took less than 5 minutes to write.
   Unfortunately, the test did not succeed, meaning that at least one
   error went undetected by the compiler in either the code as printed in
   the Book or as scanned. Scrutinizing the code more closely, I quickly
   found another error in the printed version that was easily corrected.
   However, it still did not produce correct results. After about an hour
   of searching, I finally located the error in a list of numbers in a
   table -- another error in the printed version. By reference to the DES
   algorithm description in the first part of the Book, which includes
   the correct numbers in tabular form, I found and corrected the error.
   
   8. At this point the test finally succeeded, so I knew I had a correct
   program.

As you can see, it took a long time.  Part of the problem was that the
printed copy of the code was apparently simply wrong.  Presumably if you
printed it this would not be the case.  Also, your code is shorter than
the 18 pages that Phil had to work with.  Still OCR may not be that well
adapted to source code.  Most texts use ( a lot more than {, and the OCR
may not pick out that kind of difference well.

I will also note, parenthetically, that it is a credit to Phil that he
was obviously being very honest and above-board in describing what he
had to go through, possibly to his (and our) own detriment.  If the
process of turning the book into the floppy were easier and did not
appear to require so much expertise, the government's case might have
been weakened.

Your bigger question is about the legalities of it, and that is harder to
answer.  There is a continuum of cases.  At one end we can say that
it is apparently legal to discuss cryptographic algorithms with
foreigners.  This happens all the time at international conferences.  As
long as the material isn't classified, you can talk about the technical
issues.  At the other end, it is at present definitely illegal to export
a working cryptographic device.  In between there is a gray area.

Currently it appears that exporting cryptographic source code in machine
readable form on magnetic media is illegal, at least pending some
resolution of the Karn suit.  Probably exporting it in other ways, such
as by email, would be treated the same.

My guess is that exporting in machine readable form on paper, such as by
a bar code, would also be equivalent.  There is a little more effort
involved in scanning it in, but if the bar code has good redundancy and
is reliable, it is not much more.

The next step is printed source code.  There are fonts (or other tricks,
such as per-line checksums) which can be used to make scanning this in
relatively reliable.  I don't have enough experience to know how good it
can get.  But let's suppose it were practically error-free.

By the reasoning above, this would also be restricted.  OCR'ing the text,
if it can really be done mechanically and automatically (which is clearly
not the case with the technology that Phil Karn had access to) is not
much different from getting it on a floppy.

Yet we know that at least in the case of Applied Cryptography the book,
export permission was granted.  So at least in some cases, printed
source code can be exported.  I understand that the PGP source code
book is in an OCR friendly font.  It would be interesting to hear
whether Phil's experience above is actually made easier with the PGP
source code book.

I think the bottom line is that the government will restrict any method
which makes it significantly easier for a foreigner to get working
source code than by typing it in from a book by hand.  (BTW, Phil's
lawyer did have two secretaries do that.  It took under 3 hours,
although presumably the code was subject to some of two same printing
errors that Phil had to fix in his test.) So my guess is that
technically you could get in trouble by doing what you propose.

I'm not a lawyer though -

Hal