ietf
[Top] [All Lists]

RE: Client and server authentication for email (was: RE: Last Call: 'Email Submission Between Independent Networks' to BCP)

2005-06-11 09:27:00
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(_at_)windows(_dot_)microsoft(_dot_)com> 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(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf





_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf



<Prev in Thread] Current Thread [Next in Thread>