Subject: Re: PEOPLE WITHOUT CRYPT(), BEWARE!!!
To: Larry Lee <email@example.com>
From: Chris G Demetriou <Chris_G_Demetriou@LAGAVULIN.PDL.CS.CMU.EDU>
Date: 02/19/1995 10:57:56
> It appears from the above comments that it is OK to export working
> encryption algorithms (maybe hashing would be a better term) as long
> as they can't be reversed with decryption. The purpose of password
> encryption algorithm has been to produce an encrypted value that
> is difficult to be reversed engineered into something that is typeable.
> This has always been the case with the passwords, why has there been a
because the file that implements the encryption, crypt.c, also
normally implements decryption.
The point of the exportable crypt.c (i.e. the one that's exportable,
_not_ the one that's not) is that it has decryption intentially
disabled; code has been removed, to make it non-functional.
> What are the limits of the restrictions on encryption/decryption.
> For example, could NetBSD include a working crypt function athat
> xor'd the data with a site selected value or would that violate
> the law as well?
i'm not entirely sure on the exact restriction, but it's basically
"Strong crypto". Strong cryptographic mechanisms can't be exported
without a license.
This includes things like DES, PGP, etc. the encryption contained
in the crypt.c file is DES, which is strong crypto, therefore a
functional version can't be exported without a license (and said
licenses are damned hard to come by, even for crypto as weak as