WHAT IS THIS?

This  is  the  source  code  used  to  erect  an  export  barrier for automated
cryptographic    software    export    in    the    USA.    It   is   used   at
http://www.cryptography.org,  and  you  are free to adapt it to your own sites,
provided  that  you  do so at your own risk. This is freeware with no warranty.
In  particular,  I  will  not  support  or  guarantee this software in any way,
especially  with  respect  to predicting the U. S. Government's response to it.
I  believe  that  this  is equivalent to a "best effort" attempt to comply with
the   current   export   regulations,  but  the  regulations  are  unclear  and
unconstitutional   when  taken  at  face  value,  so  your  interpretation,  my
interpretation,   and   any   representative   of   the   U.   S.  Government's
interpretation will likely differ to some degree.

This  export  control  system  assumes  a  *nix  system.  On  an  NT  server, a
different  approach  would  be  required, such as having a cgi program directly
serve the controlled files.


WHAT DOES IT DO?

From  the  standpoint  of  the  user, a form is presented that asks 3 questions
that  must  all  3 be answered "Yes" with radio buttons that default to "No" to
gain  access  to  a  library  of  cryptographic  goodies.  The  CGI script that
evaluates    the    answers   believes   the   web   guest's   answers   unless
reverse-resolution  of  the  IP address of the browsing machine makes the guest
look  like  a  liar.  This  is  not  spoof-proof,  and  certainly can't prevent
exports,  but  short  of  issuing  national ID cards with digital signature key
certificates  or  embedding  the "mark of the beast" on people, it was the best
I  could  do with a reasonable amount of resources. The point of this system is
to  (1)  allow  easy distribution of cryptographic software to legal recipients
of  same  without  any manual intervention required to validate transactions or
people  downloading,  and  (2)  to  keep  me  out  of  trouble  with  the U. S.
Government. So far, so good.


HOW DOES IT WORK?

All  of  the  cryptographic  goodies  are  stored in a directory structure that
includes  a  hidden  directory  name.  Given  that hidden directory name, it is
trivial  to  download  the  controlled  files  with  ftp  or http. Without that
hidden  name,  it  is  not  practical  to complete the download. Although it is
possible  to  mount  a  brute force search for the hidden name, it is generated
cryptographically  and  is  long  enough that it is impractical to do so. It is
certainly  far  more trouble to do so than to enter in via the "front door." In
my  setup,  the  root  for  both  http  and ftp access is in /var/www, which is
world  readable.  In that directory, the directory "crypto" is "executable" but
not  "readable"  (chmod  711  crypto)  by the world. In the crypto directory is
only  one  directory  and  no  other  files.  That  directory  is  readable and
executable,  but  its  own  name can't be seen by WWW or ftp guests. Under that
directory  are  whatever  other  files  and  directories  need  to be there for
distribution, all world readable.

To  discourage  publication  of  the  hidden  directory  name  in  unauthorized
places  and  to  discourage  direct  links  that  bypass  the  "front door" cgi
program,  the  name  of  the  hidden  directory must be changed periodically. I
have  experimented  with  various  periods,  and  I  think that 24 hours is the
longest  period  that  is  sufficiently  effective.  This time period minimizes
hassles  of  the directory name changing in the middle of a download or between
the  time  the  guest  is  authenticated  and  the  guest  attempts  to start a
download.  The  shortest  time  I've  seen  used is 15 minutes. That causes all
kinds of problems, especially for guests with slow modems.

At  the  same  time  the  directory name is updated, the index served up to the
authorized  guests  is  also  changed.  The  directory name is changed with the
program  called  "newdir"  and  the  index  is  updated with the program called
"newindex"  at  the same time. To run newdir, the current directory must be set
to  the  directory that the crypto directory is in. The newindex program is run
with  command  line  parameters  of  the  html  file(s) to be updated. The html
files  are  in  a  directory  that is not accessible under the html or ftp root
directories,  but  which  are  accessible  to  the  cgi  program.  The input to
newindex  is  named  with  a suffix ".dat" and its output is the same, but with
the  suffix  changed  to ".htm". Every occurance of "OOOO0000" in the .dat file
is  changed  to  the  new hidden directory name. (That is 4 capital letter Oh's
followed  by  4  numeral zeroes -- a combination chosen to be unlikely to be in
the html file in any other context.)

Because  one  of  my  design goals was that newdir and newindex must be able to
be  run  on  separate  computers, the hidden directly name is a function of (1)
the  date  and  hour  the  programs are run (as reported by gmtime()) and (2) a
20-byte  cryptographic  key.

I  call  newdir  and  newindex with a script called change_crypto_dir_name that
looks like this:

#bash

# Adapt directory names as needed. /var/www is the root of http access.
# /home/mpj is where the raw data for the html index that points to the
# cryptographic software is kept.
# This script is invoked by cron at least once a day but no more than
# once every 15 minutes.

cd /var/www
chmod 711 crypto
/home/mpj/newdir
cd /home/mpj
/home/mpj/newindex *.dat

The above script is called by cron with a crontab entry that looks like this:
6 2 * * * /home/mpj/change_crypto_dir_name

That  calls  the  script  at approximately 2:06 AM PST - a time that loading is
light  and  people in North America are more likely to be sleeping that surfing
the Web.


HOW EFFECTIVE IS THIS SETUP?

The  primary  goal  of  this  setup  is to allow me to freely and automatically
distribute  strong,  non-GAKed,  non-crippled cryptographic software, toolkits,
and  information  without  getting  in  trouble  with  the law. It is extremely
effective  at  that.  As  far  as  I know, the Feds are too busy running scared
from  friends  of  mine  like  Dan  Bernstein  to even consider handing us more
ammunition  to  be  used  against  them  by  questioning  the  legitimacy of my
system. Freedom of the press is still in the U. S. Constitution.

Of  course,  you may wonder how effective it is at discouraging export. I guess
that  depends  on  how  you  measure  it.  No  such  system can prevent export,
because  someone  who  can legally download the forbidden goods will inevitably
smuggle  them  out  of  the  country,  where  they  will be copied around until
someone  posts  them  on  a site somewhere that it is perfectly legal to do so.
In  that  scenario,  someone  broke  the  law,  but it wasn't me. The Feds, for
reasons  that  seem  good  to  them,  aren't  concerned  about  that.  They are
concerned  about  bandwidth  past  the  border  and numbers of exports. In that
sense,  I  have examined the logs of this system, and I see no obvious breaches
of  export  rules.  Of  course,  obvious  breaches  are  not allowed by the cgi
script,  so  that  is  not unexpected. It does mean that at least one potential
attack  to  this  system  (reposting of the time-dependent data) is not a major
threat.  After  all,  why  do  that  when  it  is  easier  to  just  repost the
downloaded files?

The  security  of  this  system  is  not  well  balanced. The block cipher used
(10-round  Diamond2  with a 20-byte key) is overkill. The directory name length
(effectively  46  bits) is marginal, but then a brute force attack on that name
seriously  exceeds  the  time  to simply bypass the system by lying on the form
and using www.anonymizer.com -- or looking for the same files elsewhere.

For   what  it  is  worth,  I  did  a  search  for  several  of  the  files  on
www.cryptography.org  that  were  posted  there first, and I failed to find one
of them outside of the USA, even though it has been downloaded many times.

I  guess  the  real  value  of  this  system,  though,  is  in pointing out the
futility,  irrationality,  and  ineffectiveness  of  the  current cryptographic
export  control  regulations  by complying with them. This is a way to exercise
the  rights  that the Feds claim that I still have (while they do their best to
discourage me from using those rights).


HOW DO I CUSTOMIZE IT FOR MY SITE?

1.  (IMPORTANT)  Edit  newdir.C and newindex.C to have a new diamond_key array.
The  key  in  these  sample files is NOT the one I use, for reasons that should
be  obvious  to the casual cryptographer. (Note- if you run a site that is less
geographically  dispersed  than  mine, you could modify this to use real random
numbers  and  combine  newdir  and  newindex  to  one  program, thus making key
compromise  no  problem. Of course, you need a source of real random numbers to
do that.)

2.  Edit  noexport.C  to change the RAWPAGE, DENIED, and SOURCEFORM definitions
to  match  your  setup.  RAWPAGE  is  the full path and file name of the output
created  by  newindex. DENIED is the URL of the html page to serve the guest if
they  don't  qualify  for  access  to  the hidden goodies. (This page should be
polite  and  offer  good alternate sources of cryptographic material outside of
the  USA  and  Canada  for maximum effectiveness.) SOURCEFORM is the URL of the
form   that   asks   the   magic  questions.  A  sample  form  is  provided  as
noexport.htm.

3.  Compile  the  above  changed  programs  with  Gnu  C++  (using the provided
makefile).  You  may  need  to  tweak  the  NO_UNISTD  definition  in makefile,
depending on your target system.

4.  Edit  noexport.htm  and  index.dat  to  taste.  (Be  careful with the legal
wording  in  noexport.htm.  I  recommend  using  it  as is or modeling it after
http://www.pgp.com's  cryptographic  control  questions, unless you hire a real
lawyer to advise you or you study the law yourself).

5.  Edit change_crypto_dir_name to fit your setup.

6.  Use  crontab  to  set  up calls to change_crypto_dir_name on your preferred
schedule.

7.  Test your setup to make sure that it works.

I  could  have  made  this  a  little more friendly, but the above system works
fine  for  me,  and  using  this is hopefully easier than reinventing the wheel
from scratch.

WHO WROTE THIS STUFF?

The  cgic.h  and cgic.C files were written by Thomas Boutell. Buy his excellent
book  on  CGI  programming  for  more  information  on  those. The rest of this
collection  was  written  by  Michael  Paul  Johnson  <mpj@ebible.org>.  It  is
unsupported  freeware.  Use  it  at  your  own  risk  and  only  after you have
evaluated it for suitability to your application.




