Support OTR-encryption #82

Closed
Dahie opened this Issue Aug 24, 2012 · 17 comments

Projects

None yet

5 participants

@Dahie
Dahie commented Aug 24, 2012

Is it possible in a future release to support OTR-encryption?

@ge0rg
Collaborator
ge0rg commented Jan 15, 2013

In theory it is possible, but I see several problems, which are a showstopper for me:

  1. The OTR spec implies you are not allowed to store the messages in plaintext. The default android way to keep the content of your chat window is a SQLite database, which means that chat window content is always and automatically stored to flash.
  2. OTR requires key synchronization between sender and receiver, which might impose challenges on mobile networks
  3. My previous experience with OTR shows that clients tend to get desynchronized (due to multiple presences or other reasons I was not really able to debug), causing more trouble than success.

If somebody wishes to implement OTR in yaxim, feel free and I will review the patches. However, I am not going to write the support myself anytime soon.

@rigid
rigid commented Dec 2, 2013

There are examples for OTR on android like Xabber, Gibberbot, Beem or ChatSecure.
Maybe that's useful.

@ge0rg
Collaborator
ge0rg commented Dec 5, 2013

Gibberbot/ChatSecure is doing "the right thing" by allowing encryption of all app data. This is a somewhat paranoid approach, but appropriate for the target group. yaxim can not compete with this level of security, by design.

My biggest problem (besides of the sync issues immanent to OTR with multiple/mobile/offline clients) is that by adding OTR to yaxim I would create a false sense of security for the other party.

By sending OTR-encrypted messages to you, the other user would expect these messages not to be stored in plain-text on your device. The only two options to achieve that are:

  • only keep messages in RAM. They will be lost randomly when your Android is low on memory (i.e. when opening Maps)
  • encrypt the app storage, like ChatSecure does. This is a great security feature, but it would require you to unlock the app every time you start it up (or when it is killed due to low memory). This is out-of-scope for yaxim.

As far as I can see from here, both Xabber and Beem violate this expectation.

@eighthave

OTR has nothing to do with data at rest, only data on the move. This is one of the many ways that OTR is very different than OpenPGP. Mass surveillance has only to do with data at move. Mass surveillance, made famous by the NSA leaks but in use in many countries all over the world, has only to do with data on the move. OTR+Tor is the best existing solution to mass surveillance.

Think of OTR as like an envelope in old fashioned mail. It protects the contents of the message while its in transit. Once the envelope is opened and stored at a house or office, (e.g. like data on your phone) then anyone can break into it and steal the message.

@ge0rg
Collaborator
ge0rg commented Dec 27, 2013

TLS and a trustworthy XMPP server are already a good solution to prevent mass surveillance, OTR only adds to that if you use an untrusted XMPP server or a pair of servers without encrypted S2S. However, communication meta-data is of equal importance to the NSA and OTR does not protect that.

You really do not need to convince me, especially as you did not address my main point - with OTR there is an expectation that your communication party is not storing your messages ("off the record"), which yaxim can not fulfill. Instead, you can provide patches that implement OTR support in yaxim, and I will be glad to review and integrate them.

@allo-
allo- commented Feb 23, 2014

If you do not want to support OTR, can you filter OTR "garbage" and return a "OTR not supported" message to the sender?

@ge0rg
Collaborator
ge0rg commented Feb 23, 2014

I am not 100% opposing an OTR implementation, I just lack the time to do it myself and want to warn people about its side effects. Is there a standard way to inform the other party of missing OTR support?

@allo-
allo- commented Feb 23, 2014

Seems, that OTR-Clients detect if the other client has OTR. But if you are logged in from multiple locations, the client detects that pidgin uses OTR, and sends OTR to pidgin and beem.

So there should be two things:

  • notify the user, there is a OTR message, which is not supported
  • notify the sender, that one of the ressources does not support OTR. Maybe ask the user, if he wants to chat with beem (without OTR) or if chatting with the other client is fine and beem should ignore the messages for the moment.
@ge0rg
Collaborator
ge0rg commented Feb 28, 2014

The other client should be fixed so it does not assume OTR support from one XMPP resource just because a different XMPP resource supports OTR. Besides of that, even if different resources do support OTR, they do not automatically share the same key state, so they are not able to decode the same messages sent to them. I think OTR needs to be redone so that every chat is actually a "group" chat, with the "group" being the set of all resources of both users. However, this needs a way to add and remove resources to that "group".

@allo-
allo- commented Feb 28, 2014

When i recommend yaxim to a user, i do not care about other clients being broken. I care about the user seeing strange gibberish or not. I am a bit indifferent about OTR (i see your point in "we cannot provide the full privacy"), but i do care about the user experience for not so geeky users.

For the other thing: groupchat between all resources seems reasonable. And implementing OTR is of course one of the easiest things to avoid displaying raw OTR-messages to the user ;).

@ge0rg
Collaborator
ge0rg commented Feb 28, 2014

That is a great attitude. However, it is not yaxim's task to work around bugs in other clients. If you see a client sending OTR to a resource not supporting it (like yaxim), please file a bug with the sending client, not with yaxim.

@allo-
allo- commented Feb 28, 2014

If you really insist on this, i guess you cannot recommend yaxim to newbies. When somebody uses a broken client, the not so technical user is scared away.

Just like another client (do not remember, maybe chatsecure?), which displayed the whole ssl-certificate fingerprint on first connect. Good thing to do, but no good thing to do to support endusers.

Sorry for bothering you with such stuff, you and me do not really care about, but i am trying to get some users from proprietary messangers to xmpp, and would really like a client they can use :).

@ge0rg
Collaborator
ge0rg commented Feb 28, 2014

Seriously, if I imagine being an unsavvy user, and I get a gibberish message, I will blame the sender, not so much the client. And if the sender is tech-savvy, he should better be able to tell our user what went wrong. I have really limited time, and I can not work around implementation problems in every broken XMPP application.

Regarding SSL certs, yaxim is also showing a cert, and some people just do not understand what it is good for. Nevertheless, this is something that should not happen more than once and be taken care of by the user's tech-savvy friend. IT security is complicated, after all.

@allo-
allo- commented Feb 28, 2014

Sorry, the typical whatsapp user will then respond via whatsapp "your xmpp is shit, answer me here". You may have a second chance, but when the next contact sends gibberish, the frustration will accumulate ...

And anyway, it there are broken clients (i guess with the handling of multiple ressources, which is pretty transparent to the clients), the problem will occur often. And even the sender may not be fully aware how to fix it. When i install two friends yaxim and pidgin and one sends a message with pidgin and gets a answer "you send me a lot of broken stuff", he may not be able to find how to disable it. And when he manages to find it, he will advice others "disable the OTR plugin and you never have the problem again".

But if you set this to WONTFIX, okay. I just wanted to give some feedback with my opinion about newbie-friendly interfaces.

@ge0rg
Collaborator
ge0rg commented Feb 28, 2014

As I wrote in my blog post, this issue needs to be fixed in the sender client anyway. Whenever you, personally, encounter this issue, please spend your energy to open a bug report with the respective sender client. This issue is for implementing OTR in yaxim, not for working around broken OTR implementations in other clients (feel free to open a different issue for that, though; I would keep it open for a long time probably).

@allo-
allo- commented Feb 28, 2014

Agreed, the discussion got a bit out of the scope of this bug. I opened #118 for this issue.

@ge0rg
Collaborator
ge0rg commented Feb 3, 2017

With the advent of OMEMO, there is no more use in implementing OTR. OMEMO is more modern, allows multi-party communication and doesn't suffer from incorrectly implemented client plugins.

@ge0rg ge0rg closed this Feb 3, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment