SMP is an optional component of OTR. The Pidgin plug (I've not used it in a while) gave you a number of ways to verify the other party is the party you thought they were. SMP being one, verifying the other side's public key being the other off the top of my head (the tutorial in the article covers both methods).
Unless you're going to endow some central party as being the ultimate source of trustworthiness (which has worked less than ideally in the case of SSL certificates), there's not too many options that 'simply work'. I'd say SMP is a whole hell of a lot better than trying to verify the other side's public key (since in SMP, you can plan that ahead... you can't verify keys that have yet to be generated).
What scheme would you say would work better than being able to use either SMP or the hashes?
Posted Aug 1, 2012 6:32 UTC (Wed) by josh (subscriber, #17465)
[Link]
I'd argue that much of the time SMP represents a net loss in security, due to the higher potential for misunderstanding its purpose and the type of shared past experience that suits that purpose. A fingerprint comparison process has a known level of security, and a key fingerprint has a known amount of entropy. How many bits of entropy does a shared past experience provide?
Martin: Off the Record Messaging: A Tutorial
Posted Aug 1, 2012 11:44 UTC (Wed) by tialaramex (subscriber, #21167)
[Link]
I don't think it results in a real net loss here. Somebody has to make the identity decision. In a distributed system like OTR each individual person makes their own decisions and those who make poor decisions can suffer for it (but because of the perfect forward secrecy their conversation partners shouldn't suffer unless they've made _other_ bad decisions).
In the centralised systems we all pay for the poor decisions of a handful (well, now a very large handful) of central authorities like the SSL CAs.
I think fingerprint based key management has the exact same potential for ordinary people who are not very interested in security to screw up. Most people I've ever asked to sign my GnuPG key have been willing to do so by email without ever confirming that they're dealing with me, not even making a phone call. I routinely receive emails with encrypted attachments, followed by emails with the password to decrypt them for exactly the same reason.
Where identity is most solid (e.g. close friends, conspirators, family members) the potential for strong secrets is actually pretty good. I think if you asked my (now deceased) father to try to use this to verify he was talking to me he'd write "What's the family password?" and I'd sigh and roll my eyes but any bad guy who wasn't a close family member would be screwed, because although it's a very silly password there's no way it's on record anywhere, nor is it low entropy enough to attempt a brute force (this password was intended to authenticate any non-family adults who had been deputised to collect us from primary school in an emergency).
Martin: Off the Record Messaging: A Tutorial
Posted Aug 2, 2012 0:14 UTC (Thu) by intgr (subscriber, #39733)
[Link]
> nor is it low entropy enough to attempt a brute force
Note that SMP effectively prevents brute force. If one party fails to authenticate properly, both parties will have to restart the protocol. After a few failed attempts, every human participant would give up or try another secret.
Martin: Off the Record Messaging: A Tutorial
Posted Aug 5, 2012 16:14 UTC (Sun) by tialaramex (subscriber, #21167)
[Link]
Right sorry, that was my assumption which I didn't really make clear. My father didn't teach us some brain-teasing 20 character "safe even if the passwords are hashed with plain MD5" password when we were kids. It was just good enough that it wouldn't be on anybody's first dozen things to try.
There's probably a better phrase than "brute force" for systems where you're up against human patience rather than some machine processing limit, but I don't know it.