From: "Joshua E. Hill" <jehill@w6bhz.calpoly.edu>
Date: Sun, 17 Nov 1996 14:17:02 -0800 (PST)
To: cypherpunks@toad.com
Subject: Re: RFC: A UNIX crypt(3) replacement
Message-ID: <199611172214.OAA15330@hyperion.boxes.org>
MIME-Version: 1.0
Content-Type: text/plain


I have gotten a lot of e-mail that has said basicly the same things:

	1) Don't try to redo UNIX crypt(3), S-KEY (Secure Shell, etc.)
	is better.

Well... This is most certainly the case.  And if I could force the
people in my user base to use one of these alternatives, I would.
Unfortunately, I cannot.  A fair number of the people who use the
systems that I administer log on through dumb terminals.  If I can't
successfully teach them not to hit the "Ctrl-S" key, how am I going
to teach them to do IDEA encryption in their heads?  Or MD4 hashes
for that matter?  The fact is that if I tried to use S/KEY everyone
would print out their key list for the month, and then promptly
loose it, and regenerate a new one.  Gee... Wouldn't that be secure.
I have to stay with the one password system.

	2) If your administer was worth his weight in spit, you
	would have a shadow password system, and the preexisting
	crypt(3) function would be good enough for you.

Actually, I _am_ the administrator, and I am worth my weight in 
spit.  Rather, I do use a shadow password suite.  However, as 
security professionals, you must know that it is not whether an 
attacker can break into your system, but how long it takes.  Once
there, it is not whether the attacker can gain root, it is how long
it takes (how many of the holes have been patched, and how many are
even known about).  And then to the password file. It is not whether
the attacker can crack _all_ the passwords, it is how long it takes.  
With this algorithm, I hope to increase the last of these values.

	3) The algorithm is too complex (or too simple)

The algorithm that I proposed makes use of a NMAC as a basic 
cryptographic primitive.  The security analysis of the algorithm
should follow the same lines as a hash; that is: if the basic
operator is secure, then the chaining of the operator is secure.
The NMAC is provably as secure as the key used and the underlying
hash function.

I did everything that I could to maintain simplicity throughout the
algorithm's design.  I realize that a simple algorithm is easier to
analyze and check for security.  A fair bit of the complexity is to
make it so that the algorithm is actually a NMAC. 

	4) Why don't you use FreeBSD's MD5 based crypt(8) 
	replacement?

I didn't like FreeBSD's MD5 drop in, because it lacked any
security analysis, and complexity of the algorithm prevented
any serious attempt at said analysis.  It also uses MD5, which
has not held up well to the ravages of time.  The recent
papers on easier ways to find collisions in MD5 did _not_ give
me an attack of the warm-and-fuzzies.  I would like to make use 
of an algorithm that is still thought to be secure.

			Joshua


-----------------------------Joshua E. Hill-----------------------------
|                            Thoreau's Law:                            |
|      If you see a man approaching you with the obvious intention     |
|           of doing you good, you should run for your life.           |
-------jehill@<gauss.elee|galaxy.csc|w6bhz|tuba.aix>.calpoly.edu--------