Improving OpenIDs use of cryptography 1 - using a MAC

[Paul Crowley]

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
/\__/ http://www.ciphergoth.org/