[net.unix-wizards] using encrypt

jas@druxy.UUCP (ShanklandJA) (01/10/84)

(The statement on this line is false.)

A few notes on crypt, encrypt, and setkey(3C):

crypt and encrypt(3C) use an entirely different algorithm from crypt(1).
The latter uses a trivialized version of the German Enigma that
served the Nazis so well during WWII; the former is a variant of
the DES encryption algorithm.

Unix does password encryption by taking a constant string and encrypting
it 25 times over, using the user's typed password as a key.  It also
perturbs the encryption algorithm by modifying the E-table (one
of the tables used in standard DES encryption) in one of 4096 ways.
The crypt routine takes a 2-character "salt" and uses it to decide
just how to perturb the E-table.

Now, the problem with using setkey and encrypt to encrypt and decrypt data:
unless crypt is called first, the E-table used by encrypt IS NEVER
INITIALIZED.  I have seen this "feature" in both 4.1BSD and 5.0 USG.
The standard DES E-table is kept in an array e2[].  When crypt is
called with a password and a salt, it perturbs e2[] and puts the result
in an array E[], which is subsequently used for DES encryption.

Here are two ways to get around this problem:  at initialization time,
call crypt with any old key and some agreed-upon salt (the salt must
of course be consistent among all programs that plan to encrypt/decrypt
the same data) to initialize the E[] array.  Alternatively, if source to
crypt is available, modify it so that the E[] array is initialized to
the same values as the e2[] array.  This is a pretty trivial modification.

Two final words of warning:  crypt works on 64-bit blocks.  Don't
make the mistake of taking a 3-byte string, null-padding it to
8 bytes, encrypting it, and then writing only the first 3 bytes of
the encrypted result out to disk (or whatever).  Taking those 3 result
bytes, null-padding them to 8 bytes, and decrypting will produce garbage.
Obvious, I know, but we all have our dense moments.  Second, be
forewarned that crypt is pretty slow.  Be prepared to spend about
4-5 seconds of VAX 780 CPU time to encrypt or decrypt 1024 bytes.
The only time I used it, it turned out to be so slow that I abandoned it.

Hoping this is helpful....

		-- Jim Shankland, AT & T Information Systems, Denver
		   ..!ihnp4!druxy!jas

gwyn%brl-vld@sri-unix.UUCP (01/13/84)

From:      Doug Gwyn (VLD/VMB) <gwyn@brl-vld>

The Enigma multi-rotor cipher machine was broken by Allied cryptanalysts.
The one-rotor version of crypt(1) is far too vulnerable to entrust
critical data to.

The modified DES of crypt(3C) is considerably safer, but even it is
theoretically inadequate for the encryption of a large amount of data.
No one should rely on ANY of the standard UNIX encryption software to
protect life or property.