shared secret using diffie-hellman
brad at danga.com
Sun Jun 5 02:01:24 PDT 2005
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
> 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?
More information about the yadis