Improving OpenIDs use of cryptography 1 - using a MAC

Phillip Pearson pp at
Wed Jun 1 20:58:46 PDT 2005

> 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.

This would be great for the PHP implementation; JLD has been looking
into generating DSA keys and doing DSA signing in PHP without
openssl/crypto++, and it looks like it's a *big* job.

The 'secret exchange' doesn't need to be that big a deal: it shouldn't
be too hard to have a standard URL that speaks a standard protocol and
to do something like this: requests posts key for back to

>From then on, this secret can be used for communication with users who
specify as their ID


More information about the yadis mailing list