Casual crypto
(inspired by the big thread about XMPP end-to-end security over at security@xmpp.org)
Authentication sucks. Without it, crypto is automatic and decentralized, but insecure; doing it introduces a dependency on human intervention or a trusted third party.
I don’t like trusting “authoritative” third parties, so I’m most interested in making the human intervention required as simple as possible.
Aiming for an authentication system that Aunt Tillie will use is unrealistic; there’s no reason for her to care.
But we should aim higher than Uncle Peter, who always checks SSH fingerprints and is willing to do whatever he needs to when privacy is important.
A better target is Cousin Dave, who works in IT or took a CompSci course at business school. He doesn’t know the difference between Diffie-Hellman and Blum Blum Shub, but he’s aware of crypto, he’s competent, and he’s willing to expend minimal_amount_of_effort for privacy.
This is not to say that Uncle Peter’s use cases should be neglected, just that a system doesn’t need to be 100% usable by everybody to be better than what we’ve got.
Support for short authentication strings lowers the barrier to entry nicely, without making any significant compromises.
“Atom Authentication” sucks.
While the Atom Publishing Protocol leaves implementations free to use whatever method of authentication they please, historical circumstances have associated the Protocol with an obscure authentication method that has neither a name nor a specification.
I refer of course to the method described in this article. I hesitate to call the method Atom Authentication (because that suggests a closer association with the Protocol than exists), but I can’t come up with anything better.
The idea is sound - it functions as designed and has a few advantages over Digest authentication (mostly for people stuck with crappy hosts). The algorithm is well described in WS-Security’s UsernameToken profile (which “Atom Authentication” is based on). The general form of the challenge and response are described in the Mark Pilgrim article.
But common practice and the article have diverged. While the article (and Sam Ruby) produces an ASCII nonce and sticks it straight in the X-WSSE header, all the client code I’ve seen base64s the nonce before it goes in the header, and servers seem to require it. I can’t find this specified anywhere.
This sucks. Don’t use “Atom Authentication” unless you absolutely must, and if you absolutely must please write a proper spec first.