DES export regulations. And what to do about it!

Jan Mikkelsen janm at dramba.neis.oz
Fri Jan 4 04:35:46 AEST 1991


[Somehow, I don't think this is the right place for this discussion.
 Followups to sci.crypt]

In article <18875 at rpp386.cactus.org> jfh at rpp386.cactus.org (John F Haugh II) writes:
>The amount of information required to go from Einstein to
>a working nuclear device is non-trivial.  The amount of
>effort required to go from FIPS PUB 46 to a working DES
>machine is trivial.  I have a copy of FIPS PUB 46 sitting
>somewheres in this room.

It is for DES as well ... See below ...
 
>                           The whole world of cryptography
>requires that cryptosystems be open to examination.  DES
>is published so that everyone may stare at it and uncover
>any holes they might find.  So, while I need to know how to
>create the appropriate neutron density to get a bomb to go
>"BOOM" instead of "bzzt", with DES I only need to read the
>PUBs and start typing.

Sure, many people have written pieces of software which perform DES
encryption.  It is considerably more difficult to design a piece of hardware
with specific characteristics, for example, very high encryption speed,
tamper resistance, small size, or the ability to operating in a hostile
environment.  These are the things which cannot be built using the FIPS
specification alone.  These should be sensitive, not the algorithm itself
(which it isn't).

I suspect that it was much easier for the Americans to restrict all 
implementations, rather than spending lots of time trying to figure out
which implementations to restrict, and which not to restrict.  Of course,
this is pure supposition.

Perhaps it would make more sense to allow software for export, but not
real, physical, hardware.  Ultimatly this does all the work.
-- 
Jan Mikkelsen
janm at dramba.neis.oz.AU or janm%dramba.neis.oz at metro.ucc.su.oz.au
"She really is."



More information about the Comp.unix.internals mailing list