shared secret alternative to DSA
Nathan D. Bowen
nbowen+yadis at andtonic.com
Sat Jun 4 02:30:09 PDT 2005
Paul Crowley wrote:
> Wow, thanks! I promise to be a benevolent dictator; see the
> ubiquitous posters showing me gazing into the future with benificent
History tells me it's purely ceremonial under the precise rules of a
dictatorship, but I would certainly second the nomination.
> I'm pushing quite hard for the shared secret based protocol here
I can see why. Now that I know what an HMAC is, I can't think of a
single reason to prefer DSA. (Well, actually, Java's bulit-in DSA-SHA1
behaves better than Java's built-in HMAC-SHA1, but that's Sun's problem,
maybe my problem and Ken Horn's problem, but not OpenID's. And as Paul
rightly states, fixing HMAC-SHA1 implementations on my own will be many
times easier than fixing DSA implementations on my own.)
HMAC seems perfect for OpenID.
> I'm actually more concerned about the lifespan stuff and other
> concerns raised in parts two and three, all of which is necessary no
> matter which way this goes. However everyone seems to be happy to
> agree on those changes
I'll weigh in on that: my feeling from conversations on this list and in
real life is:
the lifespans are crucial if we want our trust policies to be
we might not see any failures from the "::" separator any time soon
-- however to be safe (especially in light of Martin's IPv6 observation)
we might as well change it now, especially if we want the respect of our
> HMAC-SHA1 is a thousand times faster. It makes it possible to host
> the world's most popular OpenID server on an old Pentium under the
> stairs. A three millisecond calculation is a noticeable burden; a two
> microsecond HMAC-SHA1 one really isn't.
>> CON: secret value goes from idserver to consumer in the clear.
> This seems to be everyone's main stopping point.
> In one post you mentioned that sending secrets in the clear "looks
> bad". But to my eyes, sending public keys unauthenticated looks
> worse. Either can make it look as if the security of the protocol
> isn't very well considered, if we don't justify them explicitly. Both
> are justified only by our assumption that actually, doing bad things
> to core internet connections is quite difficult. Both are solved if
> SSL is used.
Yep, this is my big stopping point. Brad's characterization of the issue
helped me see why I've been misunderstanding the other perspectives on
First of all, I'll admit that my gut works differently -- sending public
keys unauthenticated looks better to me than does sending secrets in the
clear. That's sort of because as long as DNS is working, OpenID by
necessity will make a lot of assumptions about authenticity.
But here's the real reason:
Currently, I get the public key by making a request to a specific
hostname -- DNS is the only thing that gets my blind faith.
If the secret is exchanged in the clear, there's more blind faith
involved -- and it's not just about the "core internet". This is where I
think I haven't been clear:
I don't think I move in particularly shady circles, but I know quite a
few people who did a little experimental packet sniffing on their
college dorm networks. Whenever I worked at an ISP, I occasionally saw a
few packets I probably wasn't supposed to. On the other hand, I
certainly never played the part of an active man-in-the-middle for my
customers' encrypted sessions. I'd be too likely to get caught. This is
why I think that for our purposes, sniffing (more difficult or not) will
be more "likely" than spoofing.
I think we all can believe that every once in awhile some sysadmin with
a grudge says to himself, "I wouldn't want to jeapordize my job by doing
any 'real hacking', but I sniffed this secret key and I could take it
home tonight and use it over my cable modem any time in the next 24
hours... especially since I could use it to impersonate my
ex-girlfriend." And I think his sort of attack is what we are the most
interested in thwarting.
Brad is already exhibiting superhuman restraint by waiting before
unleashing this stuff on the public. If I were him, it would already be
too late. When he finally can't take it anymore, the installed base of
OpenID identities will be measured in 7 figure numbers. The livejournal
stats page says those identities will belong mostly to college-aged or
That's why even if I agree with the assessment of the vulnerabilities of
the core internet, I think the core internet is the least of our concerns.
I would go so far as to say that the almost-explicit role of OpenID is
to protect college girls' blogs from their bitter ex-boyfriends whose
fraternity brothers are the sysadmins on their campus networks. In other
words, unlike credit card numbers which are attractive to anyone on the
planet, a blog's attractiveness as a hacking target will increase with
the proximity of the attacker. And in the situations that are likely
with things like blogs, as proximity of the attacker increases, so does
the likelihood of the attacker's friendship with someone in a position
to sniff the network in question.
I assume that anyone could find a use for my credit card number. If I
had a blog, on the other hand, it would be most interesting as a target
for hackers that were my housemates, schoolmates, officemates, etc.
They're the ones I would most likely piss off if I got drunk and said
something stupid, and they know the people who would be the most
affected by embarassing blog posts seemingly authenticated as my own. Or
they would be the ones who made friends-only posts about what a jerk I
am, trusting that I wasn't able to read them.
And the general public aside, my geek and pseduo-geek friends with
homegrown blogs are the ones we have to convince to use OpenID. If they
all wanted to use LiveJournal in the first place, OpenID wouldn't be
More information about the yadis