Improving OpenIDs use of cryptography 1 - using a MAC
paul at ciphergoth.org
Wed Jun 1 19:38:37 PDT 2005
Brad Fitzpatrick wrote:
> How is that secret exchanged without encryption?
How is the DSA key exchanged without authentication?
OpenID already assumes that an attacker can't actively interfere with
the connection between consumer and server. If they can, they can
replace the DSA key and thus forge identities. I'm making the slightly
stronger assumption that they can't even snoop on it. Since forging
such connections on the public Internet is currently *easier* than
snooping them, this isn't really any stronger an assumption.
If both consumer and server are in colos and secure against eg DNS
poisoning, most attackers will have no opportunity to do either to them.
In practice, they will have much better luck trying to snoop on or
interfere with the "first hop" between the user agent and everyone else,
by for example listening in on wireless IP packets. I'll discuss the
implications of that later.
> LJ::secret works because LJ is the only party involved... twice. It knows
> its own secrets. (right?)
Right. But LJ::get_secret is just a carefully implemented way to offer
many secrets while storing few, so it works for this application too.
(It's possible I'm misunderstanding how LJ::get_secret works, in which
case I'll outline what I'm imagining as a good way to solve this problem).
> I'd originally done without DSA and the identity server handed out a
> "proof token" which the identity consumer could then check, by doing
> another HTTP request to the identity server, but I disliked the extra HTTP
> request which can be avoided by a consumer caching the public key.
Yup, and this achieves exactly the same thing with secret-key crypto.
\/ o\ Paul Crowley, paul at ciphergoth.org
More information about the yadis