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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]