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!
Malte: This is a PEP for XMPP. Wouldn't this enhancement be for the gabble component then?
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.
(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.
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.]
see https://github.com/WhisperSystems/libsignal-protocol-c for the protocol library
Maybe telepathy-gabble could benefit from Google Summer of Code or similar in this case?
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/)
OMEMO is now published as XEP-0384 https://xmpp.org/extensions/xep-0384.html
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?
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.
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.
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/telepathy/telepathy-gabble/issues/279.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.