new PGP tool - your opinion on ITAR regs?

[Stanton McCandlish <mech@eff.org>]

Someone just sent me this, encrypted, via anon remailer yet asking for it
to be distributed.  Go figure.  Anyway, the author thinks it may be ITAR 
controlled, but from the looks of it it's not crypto at all but simply an
incidental utility that contains no crypto code.  I'll leave it up to y'all
to figure that out though.  Here's the doc, and I'll pass on the binary to
any US or Canada folks that want it to examine it.  Don't just ask for it
because you want it, wait till it shows up for ftp somewhere, eh.  I have to
manually send it to you, and am severely limited time-wise.  Thx.


_______ begin _________

This is a hack to the pgp source files random.h and random.c to support
a hardware random number generator. 

Please distribute these file as widely as possible in the U.S.
But be aware of the following problem. The U.S. governmemt is
trying to say that the export of files relating to cryptography
is illegal. In spite of the first ammentment to the U.S. constitution
and the inalienable rights of all peoples. They might say that
ranodm.h and random.c are subject to export controls in spite of the
fact that they have non-croptographic applications. So be aware that
if you export these file from the U.S. the govnmnt may try to
prosecute, persecute or otherwise screw you! I am sure that you are
aware of this problem. As a result I can not recommend that you
export this file out of the U.S.


The hacked files are under the GNU public licence same as the original
unhacked files.

This allows a program using random.h random.c to use a hardware random
number generator. Thus one need not type in all those stupid keyboard
timing strokes. The source files from 2.3a have been hacked.

The hack has been "ifdef"ed so that the hacked files compile the same as
the unhacked files unless certain "DEFINE"s have been defined.

I have tested this hack under MSDOS and OS/2. I do not know about other
machines compilers.

RANDDRIVER
This hack supports the following combinations:
A hardware RNG supported by a OS drive.
It is assumed that the driver can be opened as a character
oriented device. Each byte read is a random byte.
(Tested under OS/2)

RANDHARDPORT
This hack attempts to directly read random bytes directly
from a bus hardware RNG. It is assumed that for each
inb instruction that you do on the port you get one random byte.
If necessary a spin wait can be done that enough time has passed
to insure random indpandance. (RANDHARDWAIT)
This has been tested under the MS-DOS program loader.

RANDHARDPORT and TESTCFG
same as above except that OS/2's IO driver TESTCFG$
is used to get random bytes from the port.
(Tested under OS/2)

HARDRANDOM

is defined if you have a hardware RNG.

RANDDRIVER

is defined to be the filespec of the random number generator if you have
a software driver.


RANDHARDPORT

is defined to be the port number of the random number generator if random.c
is to directly access the random number generator.

RANDHARDWAIT

is the number of timer0 clicks that must be waited for  to assure that
the next random byte will be independant from the last. 

TESTCFG

is defined is you want to use OS/2's TESTCFG driver to read a bus RNG
with the port address spedified by RANDHARDPORT.

UUENCODE ZIP file follows which contains the source!
table
 !"#$%&'()*+,-./0123456789:;<=>?
@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_
begin 666 0.zip
[...]

_________ end ___________

--
Stanton McCandlish * mech@eff.org * Electronic Frontier Found. OnlineActivist
"In a Time/CNN poll of 1,000 Americans conducted last week by Yankelovich
Partners, two-thirds said it was more important to protect the privacy of
phone calls than to preserve the ability of police to conduct wiretaps.
When informed about the Clipper Chip, 80% said they opposed it."
- Philip Elmer-Dewitt, "Who Should Keep the Keys", TIME, Mar. 14 1994