Christian, Many thanks. This is _hugely_ helpful to me and, I assume, to others. john --On Saturday, 11 June, 2005 09:13 -0700 Christian Huitema <huitema@xxxxxxxxxxxxxxxxxxxxx> wrote: >> (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 mailing list > Ietf@xxxxxxxx > https://www1.ietf.org/mailman/listinfo/ietf _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf