W3C home > Mailing lists > Public > ietf-tls@w3.org > July to September 1996

Re: Passphrases in or out

From: Steve Petri <petri@litronic.com>
Date: Mon, 05 Aug 1996 17:17:03 -0700
Message-Id: <32068EFF.72A9@litronic.com>
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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:17:11 UTC