shared secret using diffie-hellman

Brad Fitzpatrick brad at danga.com
Sat Jun 4 18:34:03 PDT 2005


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.

Props to Ben Trott for telling me about DH.  Anybody correct me if I
understand it wrong.

Diffie-Hellman:

1) If consumer doesn't have shared secret handle:

    consumer --> idserver  (no UA involved, not that it'd matter)

        openid.mode=get_dh_params

    idserver -> consumer

        p = prime
        g = base
        pub_key = ....
        secret_handle = opaque string (probably "p/g/pub_key/last_privkey_gen_time/nonce/hmac-of-it-all")
        expiry = 86400

        consumer then maps that secret_handle to p, g,
        pub_key_idserver, and its own priv_key it then generates.  at
        this point, the consumer knows the shared secret before the
        identity server does, but the identity server did the harder
        part of finding p and g.  (design req: consumers dumber than servers)

2) Once it has that, it works mostly as before:

    consumer --> UA -> idserver

         openid.mode = checkid_immediate
         openid.secret_handle = <that opaque string>
         openid.pub_key = <consumer's public key for that secret_handle>

    (now the idserver knows the shared secret, since it sees the
    consumer's public key.  after it parses/validates secret_handle is
    valid too, of course, based on the hmac-of-it-all.)

    idserver -> UA (redirect) -> consumer

         openid.mode = id_res
         openid.secret_handle = <that opaque string>
         openid.hmac = HMACSHA1( shared_secret(secret_handle), plain )



It's no more HTTP requests than the plain-text exchange, it makes
people happy, and the only addition req on consumers is bigint
support (widely available).  No primality testing, etc.

Thoughts?

- Brad



More information about the yadis mailing list