- From: Steve Petri <petri@litronic.com>
- Date: Mon, 05 Aug 1996 17:17:03 -0700
- To: ietf-tls@w3.org
Bennet Yee wrote: > > I'm afraid, upon rereading your original message, that I may have answered > a slightly different question than that which you had posed. It is true > that if the key choice is not good, then eavesdroppers may use the traffic > in an off-line dictionary attack to recover the key. I was addressing a > different question, that of whether assymetric cryptography is required to > perform such an authentication -- which is why I added at the end that > users must chose passphrases with enough entropy. > > My apologies for misunderstanding your question. No problem, your response helped me to better understand my own question <g>. I do think, though, that in the final proposal, the shared MAC secret should not be allowed to be derived from the passphrase. Many users will choose low entropy passphrases, and a successful dictionary attack of a transcript might cause the entire TLS standard to be perceived as weak. Dan Simon wrote: > Fortunately, the proposal *does* involve > asymmetric crypto--for key exchange. Once a (strong) key has been > exchanged using asymmetric cryptography, the (as-yet-anonymous) client > and (already-authenticated) server share a fresh, random secret > (presumably) unavailable to the attacker, and can use that secret to > protect the shared-key-based client authentication transcript. So it seems that the client code will come up with a (high entropy) random number, and encrypt it with the Server's public key. Is that correct? Is there a provision in the proposal to deny service to an account which is being dictionary attacked directly, or will this be left up to the implementation? -- Steve Petri petri@litronic.com Litronic Industries (714)545-6649
Received on Monday, 5 August 1996 20:17:48 UTC