[2275] in Kerberos
Why call DES routines directly? (was Re: Kerberos DES <> MD5)
daemon@ATHENA.MIT.EDU (Dirk Husemann)
Thu Oct 8 18:49:25 1992
Date: Thu, 8 Oct 1992 20:57:22 GMT
From: husemann@faui45k.informatik.uni-erlangen.de (Dirk Husemann)
To: kerberos@shelby.Stanford.EDU
kaufman@kibitz.enet.dec.com (Charlie Kaufman) writes:
>>I believe that MD5 is patented by RSADSI in the US of A. It may be used
>>only under license from RSADSI in this country.
>MD5 may or may not be patented, but in any case RSADSI has made it
>freely useable without payment of royalties (unlike the RSA algorithm
>itself). The notice in the model code in RFC 1321 includes the following text:
...
>Encryption used for data integrity protection (either via DES or MD5)
>is easier to license for export than encryption used for data privacy.
>But if you use MD5 for data privacy (which is possible but
>cryptographically unproven), you're in the same soup.
>It is possible to remove encryption for privacy from Kerberos and get a
>fairly general export license. Digital has done so with Kerberos V4.
>Unfortunately, that is not the same as freely distributable and - at
>least in our case - part of the price was not distributing source code.
> It did not require removal of DES.
Why do we need to make calls to DES directly? Why not call a routine hurzit() or
dehurzit() that is defined in a header file
(a) US: calling des_encode() (or something like it) or des_decode
(b) Non-US: just calling a routine that does nothing
As there is a crypt.c (DES) implementation available with the GNU libc which
has been done outside the US (in Denmark if I'm not mistaken) we (i.e. those
of us outside the US) could then easily substitute the appropriate routines
and make the SW available again (which of course could be imported to the US
--- but not exported again ... You may stop weeping now)
Dirk Husemann
---
