Bug 93090 - telepathy-gabble should support OMEMO encryption
Summary: telepathy-gabble should support OMEMO encryption
Status: NEW
Alias: None
Product: Telepathy
Classification: Unclassified
Component: gabble (show other bugs)
Version: unspecified
Hardware: Other All
: medium critical
Assignee: Telepathy bugs list
QA Contact: Telepathy bugs list
URL: http://conversations.im/omemo/
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-11-24 06:17 UTC by Malte E.
Modified: 2017-04-17 19:23 UTC (History)
19 users (show)

See Also:
i915 platform:
i915 features:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Malte E. 2015-11-24 06:17:24 UTC
There is an ongoing debate about OTR encryption in telepathy. The developers have argued that OTR was flawed (which is true), the proponents of OTR have argued that it's the best we have, the de facto standard and pretty much the best we can get from a security standpoint, which is also true, IMHO.

To fix this problem temporarily, developers of telepathy front ends have implemented OTR in their products, a solution that works, but kind of defeats the point of having a unified messaging framework across platforms.

But there seems hope: the android XMPP client conversations now has OMEMO, derived from Signal's axolotl and supposed to have all of OTR's disadvantages while solving all its problems.

I am no cryptography expert, but I do want all my chats encrypted. OMEMO seems to do that without the hassle that OTR has (allowing multiple clients and delivery of messages stored on the server without the client receiving gibberish).

So I would very much like to see OMEMO implemented in telepathy to help it become the new standard and make privacy a little less cumbersome. To me, just like to many others, privacy isn't optional. If you refused to implement encryption because OTR was flawed in your opinion, then you have no reason not to implement it now!
Comment 1 Paul Bryan 2015-11-24 17:47:08 UTC
Malte: This is a PEP for XMPP. Wouldn't this enhancement be for the gabble component then?
Comment 2 Malte E. 2015-11-26 05:09:32 UTC
Paul Bryan: I don't understand the technical details. Is there any reason OMEMO would not work with other protocols? Maybe somebody more experienced could answer that question and possibly change the component of this bug accordingly. Since OTR has some serious problems when it comes to usability, it may be desirable to use OMEMO on other protocols as well. Although I see no reason why somebody using a third party client would not have an XMPP account as well.
Comment 3 AJ Jordan 2016-01-07 07:20:23 UTC
(In reply to Malte E. from comment #2)

> Paul Bryan: I don't understand the technical details. Is there any reason
> OMEMO would not work with other protocols?

OMEMO relies on XMPP PEP for publishing key information, so it will require changes to run over other protocols.
Comment 4 Navid Zamani 2016-01-08 23:03:52 UTC
It is definitely alright, to make this part of Telepathy’s XMPP component.

In fact it would be preferred by me, if unencrypted connections weren’t even possible at all on all computer devices on the planet. :)



[Side note about the UI: Generally, the unified UI should be able to manage both encrypted and unencrypted connections and transitions between them, no matter the underlying solution. In any case, it just needs to show if the conversation is encrypted, if the message will be encrypted when sending, and a dialog for key fingerprint verification.]
Comment 5 daniel.scharon 2016-08-09 11:37:07 UTC
see https://github.com/WhisperSystems/libsignal-protocol-c for the protocol library
Comment 6 Marcin Mielniczuk 2016-10-28 08:14:10 UTC
Maybe telepathy-gabble could benefit from Google Summer of Code or similar in this case?
Comment 7 daniel.scharon 2016-10-31 12:08:31 UTC
If I understand the Proto-XEP (https://conversations.im/xeps/multi-end.html) correctly, OMEMO needs XEP-0280 (https://bugs.freedesktop.org/show_bug.cgi?id=78093) and XEP-0313 (https://bugs.freedesktop.org/show_bug.cgi?id=90838) to fully function. So these should be tackled first.

Regarding the standardization process at the XSF, everything points to the direction that the standard definition of Olm will be used (https://matrix.org/docs/spec/olm.html) as well as their reference implementation (https://matrix.org/git/olm/tree/)
Comment 8 daniel.scharon 2016-12-09 09:22:09 UTC
OMEMO is now published as XEP-0384 https://xmpp.org/extensions/xep-0384.html
Comment 9 diane 2016-12-09 22:38:45 UTC
When I had previously skimmed the OMEMO spec I saw it referring to Message Carbons (XEP-00280) and Message Archive Management (XEP-0313) which we don't have yet. (I think there are patches in bugzilla that need review and merging).

But it looks like all we actually need for OMEME to at least partially work Personal Eventing Protocol (XEP-0163)? The other protocols are just for a better usability?
Comment 10 daniel.scharon 2016-12-12 12:14:09 UTC
Yes, I first had the same impression, but it really seems that Message Carbons and MAM just add another comfort level and the only real hard dependency is PEP.
Comment 11 Randy Barlow 2016-12-12 16:10:00 UTC
I believe you are both correct - OMEMO was designed to be a crypto system that was friendly towards MAM and carbons since OTR cannot work with either of them. With OTR, any encrypted communications have to happen live and can only happen from one device to one device. This is pretty limiting if you like the convenience of having message history shared among devices. OMEMO works by encrypting messages for multiple devices and does not require them to be actively online.

However, OMEMO doesn't use either of those extensions to work so it does not require them. Supporting OMEMO would still be beneficial even if telepathy-gabble doesn't support those extensions, because MAM and carbons can happen server-side without client involvement, allowing other clients the user has (like Conversations) to still benefit.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct.