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