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

From: "Christian Huitema" <[email-masked]>
Date: Sat, 11 Jun 2005 09:13:23 -0700

> 	(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
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: John C Klensin <[email-masked]>
Date: Sat, 11 Jun 2005 12:26:45 -0400

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
<[email-masked]> wrote:

> 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
>

---

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Sun, 12 Jun 2005 00:25:08 +0200

Have some security oriented multimodal work being carried in the IETF?
jfc