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