Path: utzoo!mnetor!uunet!munnari!otc!metro!ipso!runx!colinm
From: colinm@runx.ips.oz (Colin McCormack)
Newsgroups: sci.crypt
Subject: Re: distribution of sensitive software like DES
Message-ID: <1392@runx.ips.oz>
Date: 3 Mar 88 19:09:53 GMT
References: <8801281211.AA13780@decwrl.dec.com> <8802162241.AA16997@armagnac.DEC.COM> <2275@geac.UUCP> <4143@sdcc3.ucsd.EDU> <2342@geac.UUCP>
Reply-To: colinm@runx.OZ (Colin McCormack)
Organization: RUNX  Un*x Timeshare. Sydney, Australia.
Lines: 30

Anyone could easily write a program to implement DES, given a precise
description of what DES *is*.  Surely then the definition of DES is under
the same caveat as a program which (purports to) implement(s) it.  In which
case, what *precisely* is DES?  I seem to recall that the definition accepted
by the DOD in the U.S. is related to the output of a certain encryption chip.

What exactly is being restricted?

	Is an algorithm DES if it produces the same output for given input
	as some standard DES algorithm? - Then make your code differ in
	one value (remember designer drugs?).

	Is it DES if its I/O behaviour is predicted by some specification
	of DES algorithms? - Surely the description of that specification
	is either loose enough to be coded around or precise enough to 
	be an algorithm in its own right.

I think what is actually being restricted is the flow of DES chips, because
they reduce the time for a brute force approach to cracking a transmission,
and since (at least here) Automatic Teller Machines use DES, a lot of money
is potentially at stake.

The Rivest Shamir Adelson method is more secure, from memory - although it's
under a patent restriction.

One last thought, why not send the source in DES encrypted form with the key?
Then the only people who can get at it will be those with an authorised copy
(unless it's really not very secure :-)

 Colin McCormack.