The other day I discovered a new entry for my list: appendix B of
"Cryptography: An introduction to Computer Security" by Jennifer Seberry
and Josef Pieprzyk. Both are of University College, University of New
South Wales, Australian Defence Force Academy. The publisher is Prentice
Hall, and the ISBN is 0-13-194986-1.
Earlier entries on my list include the following:
1. "Computer Networks" by Andrew Tanenbaum (both editions) - Pascal
2. "Numerical Recipes" (all editions) - Pascal, Fortran, C
3. BYTE Magazine, April 1977 - 6502 assembler
I am interested in additions to this list. Once again, I am looking
specifically for SOURCE CODE -- mere descriptions of the DES algorithm do not
count. Apparently the US Government believes that only Americans are smart
enough to turn an algorithm description into code, so they see no problem
with attempting to outlaw the export of code whose algorithms have been
freely and widely published around the world for the past 15 years.
Of course "the US Government" is not a single monolithic organism
with completely coordinated, coherent policies. For example, I
work for the U.S. government, but have never received an official
request for any ruling on these matters, because it's not my job.
On the other hand, the agency responsible for export licensing is
the Commerce Dept., and they do issue export licenses for DES, just
on a case-by-case basis and not as a blanket permission. They in
turn are guided by NSA recommendations, probably obtained over a
decade ago and never updated.
The root problem is that the people of the United States of America
have, at least through default, allowed their representatives to
sanction the imposition of such controls by the Executive Branch.
Clearly, at that level one should expect only broad policy, not
detailed evaluation of which specific systems are "safe" and which
are not. You need to argue that ALL cryptographic algorithms would
be safe to export, not that just one version of DES is, if you want
the overall cryptographic export restrictions lifted. Otherwise,
you need to talk to the Commerce Dept. and convince them that there
is some benefit to the U.S. in a blanket permission to export DES.
You could also try the argument that you seem to be relying on,
that the cat is already out of the bag, but in security matters
that is not normally accepted as a sufficient reason. There have
been many cases of compromise of secrets by news media or other
means, that are still classified even though anyone who cares can
find them out through research of publicly-available information.
Frankly, I think DES was a mistake in many ways, one of them being
any attempt at all to include it under export controls, since it
was explicitly designed as a PUBLIC method of encryption. However,
as mentioned above you need to convince the right people of that.
The problem is not the Commerce Department. They have a blanket waiver for
anything that is already freely available to persons within the US. The
problem is the ITARs, which are administered by the State Department. They
include "cryptographic machines and software" on the munitions list, and
there is no waiver for information already in the public domain.
Last week the news reported that Bush was proposing to ease up on export
controls for widely available technology. 80386 (but not 80486) systems
would be okay for export to the eastern bloc (what's left of it). Does
anybody have any specifics, especially as they pertain to cryptography?
I would like to add two entries to your list:
"Mathematical Cryptology" by Wayne Patterson (Department of Computer Science,
University of New Orleans), published 1987,
source code in Pascal beginning on page 232.
"The Standard Data Encryption Algorithm" by Harry Katzan Jr. (Chairman,
Computer Science Department, Pratt Institute), published 1977,
source code in APL. Notable in this regard is Chapter 5 which is entitled
"Bitwise walk-through of the standard data encryption algorithm"
Overall, this is a quite unusual book, and its 1977 date puts it
considerably early in the field of books containing software implementations
of cryptographic algorithms.
Editor and Publisher
9755 Oatley Lane
Burke, VA 22015 U.S.A.
Actually, it is the U.S. Department of State (rather than Commerce)
who (at this time) has primary responsibility for issuing
export licenses for crypto software. The particular part of the
State Department is the Office of Defense Trade (formerly named
The Office of Munitions Control), part of the State Department's
Bureau of Politico-Military Affairs.
Actually, NSA makes a recommendation for each commodity jurisdiction
determination which is required under category 13B of ITAR. It took me
"only" 16 months to obtain the following paragraph (under the
Freedom of Information Act) to learn that NSA's position (considerably
more recent than a decade ago) as of February 1987 was:
"Although software was developed from open source material,
the application of that information into the subject software
program contains cryptographic capabilities that are controlled
under category 13B."
The Commerce Department took the completely opposite position:
"There is no military application identified. The software is
also written without a military application in mind."
I therefore agree that "the US Government is not a single monolithic
organism with completely coordinated, coherent policies." My primary
concern is that those policies must comply with the U.S. Constitution
and thereby allow the free dissemination of open-source/published
material -- including software (ESPECIALLY FREE SOFTWARE) which is
developed directly from published algorithms.
Editor and Publisher
9755 Oatley Lane
Burke, VA 22015