shared secret using diffie-hellman
brad at danga.com
Sun Jun 5 03:07:05 PDT 2005
On Sun, 5 Jun 2005, Paul Crowley wrote:
> > CTR? Where did AES come into play? Why is any encryption necessary?
> I thought we were going to use Diffie-Hellman key agreement to protect
> the secret MAC key from snoopers in transit? Otherwise we're still
> having to do public-key-related stuff in the authentication
> transactions, which is what I was hoping to avoid
I thought the shared secret produced as a result of Diffie-Hellman _was_
the key used in the HMAC. That's what I was assuming when I sent the
first email in this thread.
> However, we can probably get away with using XOR instead of AES. The
> reply could just send the secret key ID, expiry etc in the clear, and
> XOR the Diffie-Hellman key with the secret key.
I don't see where even XOR comes into play. What's wrong with sending the
secret key's ID (I called it "handle") and expiry in the clear?
> > Single HTTP transaction to setup the shared secret, or for the identity
> > check as well?
> The flow is as before - consumer goes to server to get a secret; they
> get it in a single HTTP transaction and they can use it as often as they
> want. They then use the secret to authenticate transactions that go via
> the user agent as before.
Okay, phew. I'm not that off then.
> > Because your openid.mode in your example above seems to
> > suggest this round-trip was just for shared-secret setup, except you had a
> > payload in the second half.
> The payload is the shared secret.
What? I thought the whole point of DH was that you never sent the
shared-secret... it's inferred from both side's advertised public keys
(you named then "gx", and "gy", probably by convention)
More information about the yadis