shared secret using diffie-hellman

[Brad Fitzpatrick]

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)

- Brad