> (3) I may no longer fully understand the implications of > "dictionary attack" and suspect that at least some > application writers understand it even less well that I > do. But, if my understanding is correct, it seems to me > that, if passwords or passphrases are readily vunerable > to dictionary attacks, there are other problems and the > presence of encryption would pose an inconvenience, not > an obstacle, for the attacker. The strength of the encryption mechanism does not matter: if the algorithm has been crypto-analyzed, then the attacker can just proceed with a reverse computation. We don't know when a given algorithm will be broken, but we can suspect that any algorithm will be broken eventually. The reasonable design rule is thus to never hardcode a specific encryption or hashing algorithm in a protocol. Even with a strong algorithm, the only effective protection against dictionary attacks is "key entropy", which determines the number of trials needed before finding a match. This number follows Moore's law: attackers with 2005 computers can attempt 100 times more trials than attackers of 1995. We have reached a point where "if an average user can remember the password, there is probably not enough entropy in it". If you use simple hash functions like MD5 or SHA, challenge response mechanisms are only OK if the shared secret contains at least as much entropy as a good symmetric key. Most experts will assume that if you can, you should use a randomly generated 128 bit key. In practice, provisioning such keys is hard. If you must use a low entropy key, you may have a solution by picking a very slow encryption algorithm. Essentially, you would counter Moore's law by requiring more CPU for a single trial. For example, instead of using the simple SHA, you may want to iterate the algorithm 10,000 times. Any verification takes 10,000 times more than a simple trial, and the dictionary attack becomes impractical. On the other hand, you have increased the cost for the client and the server. You also rely on the assumption that nobody can compute the result of 10,000 iterations without iterating the algorithm 10,000 times, which may or may not be a safe assumption. CRAM-MD5 has another weakness that increases its vulnerability to dictionary attack. In CRAM-MD5, the challenge is chosen by the server, and the result computed by the client. An ill-intentioned server can thus choose a challenge, and pre-compute a database of expected results. A better algorithm should allow the client to inject some salt in the process. -- Christian Huitema _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf