Martin: Off the Record Messaging: A Tutorial

[Posted July 30, 2012 by jake]

Ben Martin has a lengthy tutorial on Off the Record (OTR) messaging on his blog. OTR is useful for realtime encrypted communication (e.g. instant messaging, IRC) and Martin's post looks at both the protocol and using libotr to add OTR support to C++ programs. "In order to operate without a web of trust, libotr implements the Socialist Millionaires' Protocol (SMP). The SMP allows two parties to verify that they both know the same secret. The secret might be a passphrase or answer to a private joke that two people will easily know. The SMP operates fine in the presence of eaves droppers (who don't get to learn the secret). Active communications tampering is not a problem, though of course it might cause the protocol not to complete successfully."

Martin: Off the Record Messaging: A Tutorial

Posted Jul 31, 2012 6:12 UTC (Tue) by slashdot (guest, #22014) [Link] (3 responses)

How does SMP compare to http://en.wikipedia.org/wiki/Secure_Remote_Password_protocol, which appears to be a more common way of doing the same thing?

SMP vs. SRP

Posted Jul 31, 2012 6:44 UTC (Tue) by idupree (guest, #71169) [Link] (1 responses)

As I understand it, SRP is an asymmetric protocol, useful for e.g. a client signing up on a website with a password the server will never know, so that the server can verify later that it's the same password as before without actually knowing what the password is.

SMP is symmetric and works only if both parties already know the secret (that's its purpose).

Do you see an obvious way to emulate SMP with SRP? (I haven't seen one.)

SMP vs. SRP

Posted Jul 31, 2012 12:42 UTC (Tue) by Otus (subscriber, #67685) [Link]

> Do you see an obvious way to emulate SMP with SRP?

SRP requires setup, so I don't think everything you can do with SMP is possible with it.

Martin: Off the Record Messaging: A Tutorial

Posted Jul 31, 2012 14:00 UTC (Tue) by erwbgy (subscriber, #4104) [Link]

In brief, SRP is a protocol for authenticating a client using a username and password (or equivalent) and negotiating a session key for integrity and/or confidentiality protection of the subsequent session. So, it is like SSL but uses passwords instead of public-key certificates and doesn't require a trusted third party.

OTR is similar in that it also uses a shared secret and has perfect forward secrecy. It is different in that there is the concept of deniable authentication where it is not possible for outsiders to tell the difference between real and fake messages and it can use the socialist millionaire protocol for authentication, as mentioned above. So OTR is designed for a different use case.

Martin: Off the Record Messaging: A Tutorial

Posted Jul 31, 2012 7:32 UTC (Tue) by rvfh (guest, #31018) [Link] (1 responses)

Is this SMP like James Bond films then? You say "In London April's a spring month" and the other side answers "while in St Petersburg we're freezing our butts off?"

Martin: Off the Record Messaging: A Tutorial

Posted Jul 31, 2012 8:36 UTC (Tue) by tialaramex (subscriber, #21167) [Link]

Not so far as we can tell, Bond appears to use a fixed call and response which means they would not be proof against eavesdroppers as a protocol like SMP is. Of course Bond might actually be doing something more sophisticated but it's never indicated to the audience.

Actively interfering in protocols like SMP can cause the protocol to fail (Alice and Bob are unable to detect that their shared secret matches because Mallory trashes the data in transit) but does not allow you to determine the secret for yourself, or to impose as either Alice or Bob if they have implemented the algorithm behind the protocol correctly.

Martin: Off the Record Messaging: A Tutorial

Posted Jul 31, 2012 15:49 UTC (Tue) by josh (subscriber, #17465) [Link] (9 responses)

This, to me, seems like the fundamental problem with OTR: it requires active action by the participants to authenticate the conversation between themselves, which means the participants have to think about questions like "what would the two of us know that nobody else could guess and that I could ask about in a way that won't reveal the answer?". Any protocol that forces its participants to answer complicated questions like that in order to have security does not work for non-experts, and worse yet it *appears* to work.

Martin: Off the Record Messaging: A Tutorial

Posted Jul 31, 2012 17:59 UTC (Tue) by dkg (subscriber, #55359) [Link]

This "handshake" is only necessary the first time you communicate with someone else from your client. After a successful completed handshake, the clients on both sides cache their peers' public keys, and can re-establish communications confidently for future sessions.

Where this falls down, of course, is when one of the parties changes clients (or, worse, connects from a new client each time).

Key management is hard. Unfortunately, key management is also necessary for a cryptosystem to work with regular humans. Having a well-integrated historical keystore is a minor risk (compromised local software gets a list of all your past contacts!) coupled with a major advantage (you can exchange communications in confidence with anyone you've communicated with successfully in the past).

OTR does a pretty decent job of key management within its domain.

Martin: Off the Record Messaging: A Tutorial

Posted Jul 31, 2012 19:57 UTC (Tue) by Kit (guest, #55925) [Link] (4 responses)

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?

Martin: Off the Record Messaging: A Tutorial

Posted Aug 1, 2012 6:32 UTC (Wed) by josh (subscriber, #17465) [Link] (3 responses)

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] (2 responses)

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] (1 responses)

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

Martin: Off the Record Messaging: A Tutorial

Posted Jul 31, 2012 21:29 UTC (Tue) by gmaxwell (guest, #30048) [Link] (2 responses)

You get _complete_ immunity to passive attackers and to dragnet data collection/archival invisibly and ~costlessly. (well there are some glitches with OTR and multiple logins on some chatnetworks which are only solved in the latest protocol versions— but on the flipside OTR also gives you transparent message splitting).

You also get active attackers which are afraid of being potentially detected and thus fail to attack for free.

And you get these things without inadvertently attaching cryptographically non-reputable authentication to your messages which may have consequences you don't expect or don't understand, or via non-ephemerially keyed cryptography (almost all SSL usage) which creates incentives for attackers to steal your systems in order to decrypt conversations in the past.

Importantly, with OTR and unlike other popular cryptographic security schemes the difficulty of getting something _better_ than immunity to passive attacks, dragnet data collection, and active attackers afraid of detection doesn't prevent you from getting all of those useful properties.

Authentication is a stick wicket in all cases. What does it even mean to be talking to a particular person? This can't be done for free, and certainly can't be done well for free. OTR makes _secure_ (e.g. not what the CA infrastructure really provides, since anyone that can fake some letterhead can usually get certs for you) authentication cheaper than almost any other system, and thats about the most you can ask for.

Martin: Off the Record Messaging: A Tutorial

Posted Jul 31, 2012 23:30 UTC (Tue) by nix (subscriber, #2304) [Link] (1 responses)

cryptographically non-reputable authentication

Do you mean 'non-repudiatable' here? They are quite different :)

Martin: Off the Record Messaging: A Tutorial

Posted Aug 1, 2012 0:43 UTC (Wed) by gmaxwell (guest, #30048) [Link]

HAH. Browser spellcheck reflex fail. (I wonder what percentage of messages could be eliminated if we could edit these things for simple copyediting…)

Martin: Off the Record Messaging: A Tutorial

Posted Jul 31, 2012 18:15 UTC (Tue) by jimparis (guest, #38647) [Link] (1 responses)

I was confused about the benefits of using SMP versus just having each party encrypt a nonce using the secret key. This comment explains that SMP additionally prevents brute forcing against weak secrets:
http://stackoverflow.com/a/9352197

Martin: Off the Record Messaging: A Tutorial

Posted Aug 1, 2012 9:12 UTC (Wed) by dvrabel (subscriber, #9500) [Link]

The response is a hash so given the challenge and response you can only brute force a set of possible master keys.