Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site druxy.UUCP
Path: utzoo!linus!decvax!harpo!ihnp4!drutx!druxy!jas
From: jas@druxy.UUCP (ShanklandJA)
Newsgroups: net.unix-wizards
Subject: re: using encrypt(3C) to encrypt/decrypt data
Message-ID: <900@druxy.UUCP>
Date: Tue, 10-Jan-84 13:48:13 EST
Article-I.D.: druxy.900
Posted: Tue Jan 10 13:48:13 1984
Date-Received: Wed, 11-Jan-84 05:27:08 EST
Organization: AT&T Information Systems Laboratories, Denver
Lines: 45

(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