This OTRv3 document has been available since at least 2012(?), so I'm not sure why there's a sudden interest in discussing it, but here was our analysis of OTRv3 at Open Whisper Systems:
1) The introduction of SIGMA in the switch from OTRv1 to OTRv2 significantly reduced the "deniability" properties of OTR. The protocol does some explicit things to provide "full" deniability, but in OTRv3 only people who've actually had a conversation with Alice can produce a complete forged transcript with Alice. More details: https://whispersystems.org/blog/simplifying-otr-deniability
2) OTRv3 doesn't work in asynchronous environments. It depends on a reliable and synchronous transport that delivers messages in-order. The messaging landscape is increasingly asynchronous, so OTRv3 is a difficult fit for modern messaging protocols. More details: https://whispersystems.org/blog/asynchronous-security
3) The OTRv3 "ratcheting" protocol is slow. It uses what we refer to as a "three step ratchet," which provides less-than-ideal forward secrecy and "future secrecy" semantics. More details: https://whispersystems.org/blog/advanced-ratcheting
We sought to improve on OTRv3 by addressing these issues in the TextSecure V2 protocol, which we believe builds on the work of OTR to provide enhanced and simplified deniability, an asynchronous-friendly environment, and optimal forward and future secrecy semantics: https://github.com/WhisperSystems/TextSecure/wiki/ProtocolV2
It also now supports group messaging and multi-device messaging, but we'll cover those in a future blog post.
That is cool and all, but let me explain why I still prefer OTR.
OTR is a library that works with many different clients (pidgin, miranda, irssi etc.). While as far as I know your stuff is pretty much baked in your products. Correct me if i'm wrong please.
And I think that is exactly the problem. I've heard of TextSecure and looked at it, but I never bothered to try it. Because it only seems to work with SMS and MMS (at least that's what it advertizes). Now in Switzerland we have the situation that a single SMS costs still about 10 cents (in USD and CHF).
But since I've got a traffic flat obviously I'd prefer to send messages over the internet. I've used WhatsApp in the past, and it really was a great replacement for SMS. But I've uninstalled it over privacy concerns.
I realize I'm kinda going off-topic, but I will take this chance to tell the people who could fix this mess where my problems are.
- TextSecure is still bound by phone number. So you can't use TOR to hide your identity. Since it's using SMS you can't deny you ever talked to someone. Your ISP can disprove that.
- Again - there is no library to just leverage your protocol, even if it's better than OTR.
Why can't we just have federated XMPP servers that use whispersystems crypto protocol and maybe some XMPP extensions or a custom protocol to push from the XMPP server to cellphones without battery drain.
If I could, I would fix this. But I don't trust my crypto skills. I could never design a secure protocol from scratch. So PLEASE create libraries regular devs can use to make the world a better place. (OTR does this! At least I would think I do have enough knowledge to use libotr correctly.)
Edit: Looking at the TextSecure code there is Push Notification stuff. So does this use SMS or a messaging server on the interwebs? I'm actually confused now.
Moxie is only one person, and the TextSecure/OpenWhisperSystems team beyond him is pretty small, and they're focusing on a lot of things now. iOS is probably (and rightly so) at the top of their lists.
TextSecure is open-source; you could split out the code you need into a library. You should NOT recommend it as a stable, mature crypto library until several people more intelligent than either of us have vetted it, but you could do a lot of useful work on it.
You'll even get paid for it by the OWS bitcoin-bot, so what are you waiting for?
You should take a look at Threema. That does exactly what you describe afaikt - except XMPP, its a walled garden - using NaCl.
Edit: I should probably elaborate:
- It uses the internet connection to transfer messages
- You can choose not to publicize your phone number and solely exchange keys via QR-codes.
- It uses NaCl which utilizes a permanent Diffie-Hellman key exchange to derive a symmetric key for authenticated encryption. If you can decrypt your messages, then you can forge them.
- There is no desktop client yet, but it is on the far agenda.
- It is not an open protocol.
Personally I don't think XMPP is a good basis for an asynchronous, encrypted network protocol. It is extremely verbose and the extension that would make it tolerable to use with unstable internet connection and multiple clients are not supported by enough clients and servers. Also it misses an encryption standard for asynchronous communication. And again I think OTR is not a good basis for that. For example afaik there are no mechanisms for recipient key selection in a non-interactive way.
PS: I would greatly appreciate some markdown dialect for the Hacker News posts, if only to typeset lists.
Oh, shiny! It's been a while since I looked at ts (a previous early version had some issues on my previous phone). If you're doing some work on the protocol level, especially if it's essentially transport-transparent like otr that's fabolous! Would it be useful for email as well?
When I saw this I really hoped I would click the link and it would say there that OTRv3 supports group chats now.
Sadly that is not the case. But support for multiple logged in clients and a key for file transfer or voice is also cool.
I would hope that means that libjingle based voice chat's can soon be OTR'd too? Now pidgin just needs a decent interface for them...
Then we convince everyone to use XMPP (or google and facebook to [re]enable XMPP federation) and we can finally drop Skype.
Group chats would be multi-party OTR (a/k/a mpotr). There are a whole bunch of people working on this, and it's not hard to find draft specs, but they are drafts; doing the crypto right for this is a really hard problem.
Why is it so hard? It doesn't work where A simply OTR encrypts her message to the keys of B, C, D and broadcasts them together? Or is it more of a problem where the continuous key re-negotiation is hard?
I'm guessing they want to set up a single session key, maintain deniability as well as authentication, and avoid leaks of the key when someone leaves the chat... It certainly seems that maintaining all of OTR's guarantees is a lot more difficult with more than one party involved.
With two parties, you either have a chat (both in conversation) or the session is ended (one or both parties leave).
If all you want is "traditional" encrypted chat alternatives might serve you better.
I'm not sure if I think re-using the OTR public keys/ids for encrypted chat that effectively isn't OTR (deniability, forward secrecy) is a good idea or not. Perhaps demand some form of indication from the user agent that clearly show group chat and individual chat is different?
As for "just broadcast multiple copies" -- that also depends on use-case. 100 person chat room? 10 person video conference? 10/100x bandwidth might not be the best approach.
Let's say Alice, Bob, Caesar and Dolores want to communicate. Couldn't Alice just open a 1 on 1 chat with Bob, then with Caesar, and then a third one with Dolores. And couldn't she then just copy and paste her message to all of them at the same time? And couldn't this be automated?
Yes, but then Caesar would have to trust Alice to relay Bob (which could be a fine and pragmatic solution for some use-cases, but wouldn't really be "otr-for-workgroups"). It would also suffer from poor network topology which could be a problem for large chats and/or high bandwith (and/or low latency) chats (file transfer, audio/video chat).
Technically there is no reason why it shouldn't have one.
If WhatsApp would just try to make their XMPP costumizations a standardized XMPP extension and enable federation on their service.
Finally we have unified Instant Messanging.
dreams again
(btw there's nothing stopping you from adding OTR support to one of the open, reverse engineered, whatsapp clients)
Why? I thought the selling point of this non-federated, proprietary jabber client was it's existing user base which would probably continue to use the official client. So what would be the benefit of an WhatsApp client with OTR?
Egzactly — the reason to use WhatsApp is that you’re pretty much guaranteed that the other side of the conversation sees your emoji, photos, videos and similar. The client-side unity is a feature.
We didn’t grow a standard on that side on our own, so it got done to us.
OTR for mobile chat messaging like WhatsApp was discussed several times. At least the former ones (do not know version 3) did not allow OTR because both clients have to be online for handshaking and exchanging keys which is very often not the case for two mobile phones.
No, because you can still verify a user's fingerprint after the handshake has been completed. That's something that you'd want to do with traditional, non-asynchronous OTR as well.
And BTW. There is a solution also with group chat and encrypted (Android and iOS): https://threema.ch . Servers and company in Switzerland and only one small one time fee.
I think you meant "too bad the source isn't published" - one can security audit code that's published but copyrighted just as well as one can audit Free (as in speech) code.
If it's not free (as in freedom) software and I can't compile the version of the sources that the community inspected, then I don't really care that some source code is publicly shown. I can't verify that it's actually the code I run when downloading the precompiled app.
Thinking of it, it would be interesting to be able to display such proof…
If you can't ensure that the code you're running is compiled from the version of the sources that the community inspected, then yes, that isn't any useful version of "the source is published".
However, verification is a technical problem, not a licensing one. It's probably -easier- for free software, but that doesn't mean that's a necessary characteristic to be able to achive the goal of 'usefully aduited'.
One of the reason I don't really use OTR as much as I would like to is that I cannot really take conversations from PC to Android phone, and then to another PC, and so on.
That's actually one of the main things that's addressed by this v3 protocol:
> Both fragmented and unfragmented messages contain sender and recipient instance tags. This avoids an issue on IM networks that always relay all messages to all sessions of a client who is logged in multiple times. In this situation, OTR clients can attempt to establish an OTR session indefinitely if there are interleaving messages from each of the sessions.
If you've ever tried to have multiple devices logged in to one account using OTR, and you've ended up with an endless spam of "invalid message, resending" or some such, this is what they're talking about. Clients that support v3 properly shouldn't do that anymore, and you should be able to keep both your PC and phone logged in without problems.
Synchronizing that info accross your devices is exactly something you'd need a protocol for. If you want to preserve the forward-secrecy that OTR offers, then you can't just "encrypt, upload" on one client and "download, decrypt" on another. You somehow need to do a key exchange between your own devices.
I believe the weakest link in OTR is its Diffie-Helman key exchange. If you break that you get the symmetric key and can decrypt everything passively. OTR has been using a 1536 bit modulus for its Diffie-Helman exchange since 2004 [1] (The weakest one from RFC 3526 [2]). Seems they are still using the same one today.
In 2004 this was probably a fine choice, especially considering the tradeoff between CPU processing (usability) and security. But considering the NSA scandal, specifically them recording all encrypted communications forever, and Bruce Schneier increasing his key lengths [3], and the ability for CPUs to process higher keylengths without any noticeable slowdown, I don't feel confident it is strong enough today.
Other than this gripe OTR is amazing and everyone should be using it.
Edit: xnyhps's post [4] concludes that only a single "cracking" of the 1536 bit group would need to occur to then decrypt any past or future OTR conversation "instantly".
OTR uses DH in a ratcheting protocol that requires attackers to continuously break new DH exchanges; it's not like TLS, where one exchange at the beginning of the session gives you the whole session.
Also, while a 1536 bit modulus isn't the best you can do in 2014 (we should all be using curves now instead of doing DLP crypto), it's probably not within reach of attackers right now. Effort doesn't scale linearly from those 1024 bit factoring problems.
> OTR uses DH in a ratcheting protocol that requires attackers to continuously break new DH exchanges; it's not like TLS, where one exchange at the beginning of the session gives you the whole session.
Please correct me if I'm wrong, but as far as I know the required effort to break multiple DH exchanges doesn't scale linearly in the number of exchanges. A single successful index-calculus attack on the used group will make breaking additional key exchanges much easier.
You're not wrong. The current state of the art puts the precomputation step at complexity L_n(1/3, 1.923)§, and additional individual discrete logs at L_n(1/3, 1.232). So individual logarithms are still subexponential and nothing to scoff at, but they do become easier, yes.
Ignoring constant factors, for a 1536-bit prime this would mean cost ~2^102 for the initial precomputation, and ~2^66 for each individual log.
§ L_n(a, c) is the usual exp(c(1 + o(1)) (log n)^a (loglog n)^(1-a)).
> The current state of the art puts the precomputation step at complexity L_n(1/3, 1.923)§, and additional individual discrete logs at L_n(1/3, 1.232).
Could you cite that? Not skeptical, just interested.
Razvan Barbulescu's PhD thesis [1]. Note that the best asymptotic complexities are a little different: the 'best' is really L_n(1/3, 1.902), but that variant is hopeless in practice (it would require truly gigantic inputs for it to pay off). Similarly, there is a "discrete logarithm factory" method, based on Coppersmith's factorization factory, but that also has very large initial costs that make it not very attractive in practice.
Yes I get that, I think there is a new DH for almost every message, much better than TLS. The problem is we have no idea what the NSAs abilities are in terms of actual cryptanalysis/cracking, but we do know that they have an immense desire for it.
RFC 3526 puts the low end of the 1536 bit group's strength at 90 bits. If some unknown weakness was found that lowers that significantly that doesn't leave things very safe.
Can somebody weigh in on the feasiblity of cracking Diffie Helman? In Cryptography Engineering, Schneir et al say "there is no known formula" for computing x & y -- but this is a different kind of problem than ciphers, and a suitably advanced mathematical formula could potentially be discovered. It seems to me that the NSA are probably pretty advanced when it comes to prime number mathematics, and it's highly likely that they have teams of cryptographers chasing exactly such a formula.
Not that I mind more people knowing about OTR, if you've seen OTR before, this isn't new: v3 of the protocol is the current version, but we've had it for a while now (Pidgin plugin has supported it since Sep 2012).
OTR is designed to help Alice to repudiate her messages when an archive of her conversation is taken by FBI from Bob's computer.
Alice might say: "Look, anyone could sign those messages as the keys were in the clear!"
Judge will reply: "Unfortunately, the collected evidence is quite believable and we have a couple of parallel constructions in place, so you don't have a chance."
I don't believe in a technical possibility to disprove someone in a court of law. Law is not mathematically defined, but interpreted quite frivolously depending on how much out of favor with the state you are.
I'd rather focus on better protecting one's identity and carefully choosing who to speak with in the first place. I'm afraid, OTR is just wishful thinking. (However, technically it's pretty cool.)
The goal is to be no less non-reputable than unencrypted plaintext is— It's a rather large shock when using encryption increases you risks, and OTR prevents this.
It, obviously, cannot make anything more reputable than plantext was.
Sadly, Adium trunk is still on libotr 3.2.1 (OTRv2) which gets so confused if either party is using multiple simultaneous logins that I just disabled it for most of my contacts who are on a mac.
1) The introduction of SIGMA in the switch from OTRv1 to OTRv2 significantly reduced the "deniability" properties of OTR. The protocol does some explicit things to provide "full" deniability, but in OTRv3 only people who've actually had a conversation with Alice can produce a complete forged transcript with Alice. More details: https://whispersystems.org/blog/simplifying-otr-deniability
2) OTRv3 doesn't work in asynchronous environments. It depends on a reliable and synchronous transport that delivers messages in-order. The messaging landscape is increasingly asynchronous, so OTRv3 is a difficult fit for modern messaging protocols. More details: https://whispersystems.org/blog/asynchronous-security
3) The OTRv3 "ratcheting" protocol is slow. It uses what we refer to as a "three step ratchet," which provides less-than-ideal forward secrecy and "future secrecy" semantics. More details: https://whispersystems.org/blog/advanced-ratcheting
We sought to improve on OTRv3 by addressing these issues in the TextSecure V2 protocol, which we believe builds on the work of OTR to provide enhanced and simplified deniability, an asynchronous-friendly environment, and optimal forward and future secrecy semantics: https://github.com/WhisperSystems/TextSecure/wiki/ProtocolV2
It also now supports group messaging and multi-device messaging, but we'll cover those in a future blog post.