shared secret using diffie-hellman
paul at ciphergoth.org
Sun Jun 5 02:53:59 PDT 2005
Brad Fitzpatrick wrote:
> K = SHA-1(gx ^ y mod p), right?
Whoops, yes, sorry! I usually think of g as an element of Z*_p, in
which case the (mod p) is implicit, but we should be making it explicit
> 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
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.
> 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.
> 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.
> 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?
Consumers don't need more than one MAC key per server. But every time
they need a new MAC key for whatever reason, every time they need to do
a new DH key agreement in order to fetch a MAC key, they must use a new
value of x.
\/ o\ Paul Crowley, paul at ciphergoth.org
More information about the yadis