Improving OpenIDs use of cryptography 1 - using a MAC
brad at danga.com
Wed Jun 1 19:24:33 PDT 2005
How is that secret exchanged without encryption?
LJ::secret works because LJ is the only party involved... twice. It knows
its own secrets. (right?)
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.
On Thu, 2 Jun 2005, Paul Crowley wrote:
> The main reason Brad asked me to look at OpenID was because as a
> cryptographer, I was always ragging on him to get the cryptography in
> these things right before setting them in stone. OpenIDs use of
> cryptography doesn't lead to an immediate break, but it can definitely
> be brought much closer to best practice. As I mentioned before, I'll
> break this into several emails.
> The first change I'd propose is good news for implementors and for
> server CPUs. OpenID doesn't need public-key cryptography at all and
> would be better off without it. Instead of DSA signing the tokens
> passed between identity server and identity consumer via the user agent,
> we can authenticate them using a secret-key MAC such as HMAC-SHA1. This
> will be vastly faster and much easier to implement. Instead of
> connecting to the ID server to fetch the DSA public key, each ID
> consumer will agree their own MAC secret with the ID server. Each MAC
> secret will have a unique name stored by the identity consumer and
> passed on as part of the authentication request. The server doesn't
> really have to store a secret per consumer - it can use a strategy like
> LJ::get_secret to map MAC IDs onto MAC secrets using a secret function.
> Generating or validating HMAC-SHA1 is over a thousand times faster
> than generating or validating DSA - and it sounds like DSA would be an
> implementation nightmare on lots of platforms too, while nearly
> everything provides a SHA-1 implementation.
> At the moment OpenID looks like a PKI solution with a severely broken
> PKI. Removing the only actual PK component would fix that. If you
> later decide you want the assurance of SSL's PKI, just buy a certificate
> for your ID server and provide an https: URL for it - the PK of the SSL
> and the OpenID cryptography will complement each other perfectly.
> Whether or not this suggestion is implemented, the way that ID consumers
> get authentication keys from ID servers needs to be part of the
> \/ o\ Paul Crowley, paul at ciphergoth.org
> /\__/ http://www.ciphergoth.org/
> yadis mailing list
> yadis at lists.danga.com
More information about the yadis