Subject: Re: crypt(3)
To: None <email@example.com>
From: der Mouse <mouse@Collatz.McRCIM.McGill.EDU>
Date: 11/16/1994 17:22:04
>>> [...] I believe MD5 to be much more secure than the standard old
>> I'm not a cryptographer, but someone here said MD5 runs faster than
>> DES, and it would require loops the way DES does.
> The issue isn't the absolute speed of the algorithm -- its the
> maximum length of passwords and the length of salt.
Well, there are also issues of just how hard it really is to invert the
algorithm, but I think anything even semi-reasonable based on MD5 is
sufficient on that point.
> crypt(3) permits maximum passwords lengths of eight characters.
This is the second time I've seen essentially this statement here. It
is true of traditional DES-based crypt(3), but NetBSD crypt(3) uses by
default an alternative algorithm that uses the entire password. Mind
you, it still uses only a 56-bit value to feed to the basic tweaked-DES
algorithm, but at least it doesn't just truncate the way the old one
did. (It also allows more salts.)
> If it is desired to slow MD5 (or, even better, SHA) down its easy
> enough to so simply by increasing the number of rounds -- no real
> reason not to increase the number by a factor of 512 or more if
> people want. This could be made tunable as well.
In my MD5-based libcrypt(), this is exactly what I've done: it uses 64
rounds by default, can accept passwords hashed with from 2 to 10240
rounds, and lets you change any of those three numbers at compile time.
> Once you've gone to changes like these there is no point in using
> DES; one might as well go to MD5 or SHA.
Actually, this is not quite true. There _is_ reason to have DES-based
crypt(3) around: compatability. We would like to run NetBSD on our
diskless Suns here at the lab I work for, but we share password files
via YP, which means that the NetBSD machines _must_ understand
"traditional" hashed passwords. Fortunately, even though we're outside
the US, we have a working DES-based crypt(3) - I wrote it myself - so I
can drop that in with little trouble. Once I get my replacement
libcrypt to understand old-style passwords (assuming you have a working
crypt(3), of course), I'll make it available for criticism.