shared secret using diffie-hellman

[Brad Fitzpatrick]

On Sun, 5 Jun 2005, Paul Crowley wrote:

> Brad Fitzpatrick wrote:
> > Here's how I'd see the shared secret setup as outlined before (and
> > corrected by Paul), but using diffie-hellman for finding the shared
> > secret, instead of passing it in the clear.
>
> I had envisaged something more like
>
> Consumer chooses p, g and random x less than p.
> p and g can be hardwired into the source if need be.
>
> consumer --> idserver
>
>      openid.mode = get_hmac_sha1_secret_dh
>      openid.dh.p = <modulus>
>      openid.dh.g = <generator>
>      openid.dh.gx = <g ^ x mod p>
>
> IDserver chooses random y less than p, and calculates
> K = SHA-1(gx ^ y)

K = SHA-1(gx ^ y mod p), right?

> idserver --> consumer
>
>      openid.dh.gy = <g ^ y mod p>
>      openid.nonce = <random nonce>
>      openid.payload = CTR_K(<payload>)
>
> where <payload> is a reply as get_hmac_sha1_secret sends in the clear,
> and CTR is AES in CTR mode, using openid.nonce to initialize the
> counter.
> Normally it's very bad practice to use encryption without a

CTR?  Where did AES come into play?  Why is any encryption necessary?

> Everything else works as before.  This means that we can do it all in a
> single HTTP transaction.

Single HTTP transaction to setup the shared secret, or for the identity
check as well?  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.

> Also it favours consumers over servers, since
> they choose the size of keys to use and they don't need to use more than
> one key.
>
> x and y must not be re-used.

I'm confused about you saying consumers don't need to use more than one
key and "x" must not be re-used.  Doesn't x influence the key?  Which key?

- Brad