From: news@hrd769.brooks.af.mil (InterNet News)
Newsgroups: comp.unix.wizards
Subject: Re: crypt()/encrypt() functions ?
Date: 23 Dec 1992 11:03:20 -0600
Organization: Armstrong Lab MIS, Brooks AFB TX
NNTP-Posting-Host: hrd769.brooks.af.mil

I think I may have messed up the attributions here.  If so, I apologize:
In article <1h8uhgINNded@usenet.INS.CWRU.Edu> cq377@cleveland.Freenet.Edu (David C. Williss) writes:
>In a previous article, vec@alnitak.Kodak.COM (Vance Cochrane) says:
>>In article <1967@enst.enst.fr>, meunier@quasar.enst.fr (Sylvain Meunier) writes:
>>>Are crypt()/encrypt() functions sames for all UNIX ? If I crypt something
>>>on a UNIX system A does it will be same on a other UNIX system B ?
>>>	S. Meunier		E-Mail: meunier@inf.enst.fr
>I believe the answer is "yes", but I'd have to try it to know for sure.
>

If for no other reason than crypt export restrictions (which is the least of
them)  crypt() and encrypt() are not guaranteed to be the same from machine to 
machine. Any system that uses a DES encryption algorithm cannot be exported 
from the U.S.  From there, many unixes use a non-DES algorithm for the 
software they are shipping out of the country, and a DES algorithm for their 
stateside distributions.  Others just stub the crypt algorithm to do a simple
XOR encoding for all their products, and let everyone know where a better
crypt() is.  Some use user supplied seeds, etc. 

  Mime assumes that a standard encrypt/decrypt is used, but I can't really
see how that is going to work to make the mail more secure, if the crypt()
is the same for every machine (since every crypt along the way will be able to
read/write it), or how the mail at the other end will be able to decrypt it at 
the other end without knowing about the crypt(), thus making it into a circle.

  For some set of computers/Unix Systems where the domain is all Unix Boxes
in the Universe, crypt() will be the same.  If your A and B box are both
members of this limited set, you are in luck.  If not, you may need to 
supply a crypt function of your own to guarantee compatibility.  A lot
depends on manufacturer and DES export restrictions. 

  I, personnally, do not necessarily want everyone on the planet to be
able to decrypt my password file, as an example.  By using the features
available using the crypt() function set, I can make it harder for
people to break into my system.

  My man page (excerpt) looks like this:

CRYPT(3)                   UNIX Programmer's Manual                   CRYPT(3)

NAME
     crypt, setkey, encrypt, des_setkey, des_cipher - DES encryption

SYNOPSIS
     char
     *crypt(const char *key, const char *setting)

     int
     setkey(char *key)

     int
     encrypt(char *block, int flag)

     int
     des_setkey(const char *key)

     int
     des_cipher(const char *in, char *out, long salt, int count)

DESCRIPTION
     The crypt function performs password encryption.  It is derived from the
     NBS Data Encryption Standard.  Additional code has been added to deter
     key search attempts.  The first argument to crypt is a NUL-terminated
     string (normally a password typed by a user).  The second is a character
     array, 9 bytes in length, consisting of an underscore (``_'') followed by
     4 bytes of iteration count and 4 bytes of salt.  Both the iteration count
     and the salt are encoded with 6 bits per character, least significant
     bits first.  The values 0 to 63 are encoded by the characters ``./0-9A-
     Za-z'', respectively.

     For compatibility with historical versions of crypt(3),  the setting may
     consist of 2 bytes of salt, encoded as above, in which case an iteration
     count of 25 is used, fewer perturbations of DES are available, at most 8
     characters of key are used, and the returned value is a NUL-terminated
     string 13 bytes in length.

SEE ALSO
     login(1),  passwd(1),  getpass(3),  passwd(5)


     Wayne Patterson, Mathematical Cryptology for Computer Scientists and
     Mathematicians, ISBN 0-8476-7438-X, 1987.

     R. Morris, and Ken Thompson, "Password Security: A Case History",
     Communications of the ACM, vol. 22, pp. 594-597, Nov. 1979.

     M.E. Hellman, "DES will be Totally Insecure within Ten Years", IEEE
     Spectrum, vol. 16, pp. 32-39, July 1979.

HISTORY
     A rotor-based crypt() function appeared in Version 6 AT&T UNIX.  The cur-
     rent style crypt() first appeared in Version 7 AT&T UNIX.


  Hope that helps?

TSgt Dave Burgess