[14475] in cryptography@c2.net mail archive
Re: DH with shared secret
daemon@ATHENA.MIT.EDU (Trevor Perrin)
Fri Oct 3 15:07:42 2003
X-Original-To: cryptography@metzdowd.com
X-Original-To: cryptography@metzdowd.com
Date: Fri, 03 Oct 2003 12:03:57 -0700
To: cryptography@metzdowd.com
From: Trevor Perrin <trevp@trevp.net>
In-Reply-To: <Pine.LNX.4.44.0310030505100.28309-100000@centaur.acm.jhu.e
du>
At 05:13 AM 10/3/2003 -0400, Jack Lloyd wrote:
>This was just something that popped into my head a while back, and I was
>wondering if this works like I think it does. And who came up with it
>before me, because it's was too obvious. It's just that I've never heard of
>something alone these lines before.
>
>Basically, you share some secret with someone else (call it S). Then you
>do a standard issue DH exchange, but instead of the shared key being
>g^(xy), it's g^(xyS)
But a bad guy MITM can try and verify guesses for S, so this is vulnerable
to an offline dictionary attack.
[A bad guy server will choose y, and will receive g^x. Now he can try
guesses for S and see if the resulting g^(xyS) properly decrypts/verifies
the client's confirmation message.]
The better approach is "DH-EKE": use S as a symmetric key, and exchange
S(g^x), S(g^y). No offline attacks, a bad guy only gets a single guess
during the protocol run.
An ever better approach is SRP, where the server doesn't need to know the
password but only a function of it. There's even an I-D for doing it with
TLS -
http://www.ietf.org/internet-drafts/draft-ietf-tls-srp-05.txt
This would be a great way of doing password auth in protocols like
POP/IMAP, HTTP, and elsewhere, since it mutually authenticates both parties
based only on the password.
Only one implementation right now (gnuTLS in the CVS version), but
hopefully that will change soon.
Trevor
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com
