▲ 133 points
back
54 comments
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.
I think the next version of TextSecure will work over the internet.
http://www.cyanogenmod.org/blog/whisperpush-secure-messaging...
It's going to allow secured messaging over the air regardless of medium. Transparently. :)
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.
wakes up from his dream
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?
You should checkout Jitsi [1]. It does voice and video over ciphered XMPP.
ZRTP actually, XMPP is used only to set up the calls (using Jingle) and for ICE discovery.
A WhatsApp client with OTR would be sweet as well.
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)
> (btw there's nothing stopping you from adding OTR support to one of the open, reverse engineered, whatsapp clients)
Except, you know, DMCA notices: https://github.com/github/dmca/blob/master/2014-02-12-WhatsA....
Yes, this is complete bullshit. Especially how they try to use a DMCA notice for trademark infringement.
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.
Modified version of OTR (by Moxie) works around that restriction.
Doesn't this solution require trust in the server caching the pre-keys?
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.
Threema seems nice. Too bad it's not free software, especially since it comes with security claims.
https://telegram.org/
You have the option to use a second layer of encryption (via OTR), even without OTR it's encrypted... but it offers OTR for the more paranoid of folk.
It even advertises as a WhatsApp private alternative.
Support for more clients... what does that mean?
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.
Does OTRv3 fix that?
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.
That seems great! Is there some app implementing it correctly, on both mobile+PC? (Linux will do)
That is really an implementation of the app. The protocol does not prevent this in any way.
You would need an app that somehow upload some info to the server and that synchronizes this info across your devices in a secure way.
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".
[1] https://web.archive.org/web/20041215062523/http://www.cypher... [2] http://www.ietf.org/rfc/rfc3526.txt [3] https://news.ycombinator.com/item?id=6376954 [4] https://blog.thijsalkema.de/blog/2014/01/17/misconceptions-a...
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)).
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.
Agreed that curves would be ideal.
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.
There are definitely methods for solving the discrete log problem. Start by looking up "index calculus".
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.)
I'm afraid you've misunderstood it.
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.
OTRv3 was released in 2012. Can a moderator please add [2012] to the title?
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.
Adium 1.6 will include libotr 4, it's already implemented in the nightlies.
Wikipedia has a good ELI5 diagram of Diffie Hellman, which OTR uses: http://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exch...
I think Open WhisperSystems' Axolotl is superior to OTR now on several levels: