>>> Doing to 3des means you (roughly) triple the attack time, which
>>> means that in about 2 years, we'll be back where we are today.
>> This does not fit with my understanding of 3DES.  I thought that
>> 3DES effectively tripled the key size, i. e. you have to derive
>> three DES keys simultaneously in order to crack.
> The point is, however, that DES isn't used in crypt(3) as a cipher
> but as a weird hash function over an eight byte value, the password,

Over a 56-bit value.  The first eight characters of the typed password
have their low seven bits concatenated to form the 56 bits passed to
the hash algorithm.  The hash algorithm is essentially to use the
56-bit value derived from the password as a key and encrypt a constant
with it.  (The algorithm is salted - tweaked in one of many ways - and
also iterated many times, but for our purposes we can think of it as
just hash = DEScrypt(key=password, value=constant).)

> and you aren't increasing this password's size

But you are.  Triple DES has, potentially, a key three times the size
of DES's - 168 bits, instead of 56 bits.  If you use the same (idiotic,
IMO) tactic of picking the first N bytes and using the low seven bits
from each, this means your password size has gone from 8 characters to
24 characters.

But if you're going to switch to 3DES, you should also do something
such that _all_ of the typed password gets rolled into the 3DES key.
Preferably a cryptographically strong hash...but if you're doing that,
you hardly need to bother with the 3DES step.  And indeed you likely
don't want to, because it means either moving your distribution site
overseas (at least for NetBSD, which is currently coming from the USA)
or leaving the rest of the world out in the cold.

> A salted MD5 or SHA of a much longer passphrase space WOULD be more
> secure because brute force searches would actually be harder.

Salted MD5 is what my replacement libcrypt uses.  With no restrictions
on the length of the pass"word", at least none imposed by libcrypt.

Of course, very little of this actually makes any difference.  The real
problem is that machines are getting fast, fast enough that you don't
have to precompute dictionaries.  Which defeats salting, too - salting
is good primarily because it balloons the size of precomputed
dictionaries; a decent size salt should make them completely
infeasible.  (Salting is also good because it prevents identical
passwords from always producing identical hashes.)

Dictionary attacks will continue to succeed, because people will
stubbornly pick bad passwords.  Password-setting programs that do
dictionary attacks help, but not everyone uses them.  Sniffing is a
greater danger, and not much helps but non-reusable passwords or
challenge-response schemes.

					der Mouse

			    mouse@collatz.mcrcim.mcgill.edu