> 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
> problem?

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
DES...).



cgd