Open Bug 1237416 Opened 10 years ago Updated 1 month ago

Implement OMEMO (Multi-End Message and Object Encryption)

Categories

(Chat Core :: XMPP, enhancement)

Product:
Chat Core
Component:
XMPP
Type:
enhancement

Tracking

(Not tracked)

People

(Reporter: nikos, Unassigned)

References

(
URL
)

Details

OMEMO (Multi-End Message and Object Encryption) is an XMPP extension for the Axolotl protocol. See more here: http://conversations.im/omemo/ Currently the only Desktop app that supports it is Gajim through this plugin: https://github.com/kalkin/gajim-omemo/
Component: Other → XMPP
Product: Instantbird → Chat Core
Summary: Implement OMEMO → Implement OMEMO (Multi-End Message and Object Encryption)
OMEMO is now based on the OLM Protocol instead of the Signal Protocol (formerly named the Axolotl Protocol). It now has an official XEP: ​https://xmpp.org/extensions/xep-0384.html Both OMEMO and OLM have been audited by third parties: ​https://conversations.im/omemo/audit.pdf ​https://www.nccgroup.trust/us/our-research/matrix-olm-cryptographic-review/ Some of this content is outdated, but a lot of documentation was written a few months ago about OMEMO here: ​https://we.riseup.net/riseup/xmpp OMEMO is being ported to Profanity.im as well ​https://github.com/boothj5/profanity/issues/658 Usability for the only desktop client that supports OMEMO currently, Gajim, is not perfect. ​https://current.workingdirectory.net/posts/2017/encrypted-mucs/ It'd be great to see InstantBird collaborate with downstream Tor Messenger in order to support OMEMO in both clients. The Tor Messenger OMEMO ticket has more information and can be found here: https://trac.torproject.org/projects/tor/ticket/17457 What are some blockers that prevent this from happening?
(In reply to kurtis from comment #1) > It'd be great to see InstantBird collaborate with downstream Tor Messenger > in order to support OMEMO in both clients. > > What are some blockers that prevent this from happening? I don't think there are any blockers other than finding a developer with the time to implement it. In fact, if this is implemented without depending on an external library like OTR, it should be easier to upstream.
Can you explain your second sentence further?
(In reply to kurtis from comment #3) > Can you explain your second sentence further? OTR support is still an addon (and not shipped by default) in large part because of its dependencies, see bug 1147369.
You could theoretically use the JS implementation of OMEMO....
Hej, I just tried to use the shim layer from https://bugzilla.mozilla.org/show_bug.cgi?id=1147369 to compile libomemo and axc. It seems to work just fine, I was able to compile and use the libpurple plugin "lurch" using it. If there're no serious concerns against the shim layer, I'll try to incorporate libomemo and axc into thunderbird. https://github.com/treba123/lurch https://github.com/treba123/libomemo https://github.com/treba123/axc
Ok never mind the links above. It's probably easier and cleaner to just make libomemo and axc able to use different crypto backends.
There was possibly a more complete version of that shim here, https://github.com/arlolra/ctypes-otr/blob/master/patches/gcrypt-shim.cpp > If there're no serious concerns against the shim layer You're better off emscripten compiling your libraries.
any updates on this? I'm really excited about it.
same here. would love to hear an update.
Sorry guys, I initially thought to do this as my bachelor theses, but I have a different topic now. Also my company, which used to use XMPP a lot, abandoned it in favor of mattermost :/ So I currently don't have time to work on this and also doubt that I'll come back to it in the future
Type: defect → enhancement

Have you any news about XEP-0384 OMEMO integration?

There are still existing interested users in support forums for this feature. Any plans for this feature after the latest improvements for Thunderbirds chat features?

(In reply to Alex Ihrig [:Thunderbird_Mail_DE] from comment #13)

There are still existing interested users in support forums for this feature. Any plans for this feature after the latest improvements for Thunderbirds chat features?

There are no concrete plans, but much of the work happening in bug 1699091 will lay the foundation where it is possible to do protocol-level encryption. Once that's complete it should be much easier to implement this.

There are no concrete plans, but much of the work happening in bug 1699091 will lay the foundation where

The bug you mentioned is - if I understand correctly - about Matrix, but this discussion is about XMPP. Or have I misunderstood something?

(In reply to Gerhard from comment #17)

There are no concrete plans, but much of the work happening in bug 1699091 will lay the foundation where

The bug you mentioned is - if I understand correctly - about Matrix, but this discussion is about XMPP. Or have I misunderstood something?

It is about Matrix, the dependent bugs of bug 1699091 start adding support for doing protocol-specific encryption (as opposed to OTR, which is implemented on top of the protocol, not at the protocol layer). I'm confident that after bug 1699091 is done we should be able to added encryption as part of XMPP (or other protocols) fairly easily.

Thank you for the information.

"By the way": What setting do I have to make so that new comments appear at the top of the list?

(In reply to Gerhard from comment #17)

There are no concrete plans, but much of the work happening in bug 1699091 will lay the foundation where

The bug you mentioned is - if I understand correctly - about Matrix, but this discussion is about XMPP. Or have I misunderstood something?

Both Matrix and OMEMO use the Double Ratchet protocol with Curve25519-HMAC-AES and XMPP is taking queues from Matrix on the more advanced cross-signing part of the protocol (they both already use Ed25519 for signatures), you can see them plan out the future signing scheme based on Matrix here: https://www.youtube.com/watch?v=oc5844dyrsc - Cryptographic Identity: Conquering the Fingerprint Chaos from XMPP Standards Foundation. Seems like 90% of the core code would be the same.

(In reply to Caleb from comment #20)

Both Matrix and OMEMO use the Double Ratchet protocol with Curve25519-HMAC-AES and XMPP is taking queues from Matrix on the more advanced cross-signing part of the protocol (they both already use Ed25519 for signatures), you can see them plan out the future signing scheme based on Matrix here: https://www.youtube.com/watch?v=oc5844dyrsc - Cryptographic Identity: Conquering the Fingerprint Chaos from XMPP Standards Foundation. Seems like 90% of the core code would be the same.

Just to manage expectations. The main benefit for XMPP from the Matrix encryption work is adding the UI parts that allow a protocol to offer its own encryption. The actual encryption implementation for Matrix is unlikely to be of much help, unless OMEMO also uses libolm, in which case we would already have that in our tree. But that's about it, most of the actual encryption backend isn't portable, while the big step forward is having a frontend for encryption that OMEMO could be built below.

Severity: normal → S3

Is Anyone interested in developing this? I just added $50 to the bounty, which I know is nothing if you have the skills to implement this feature, but I would sure love to have Thunderbird be my one-stop messaging, email, calendar application for desktop. Especially since I am getting all my SMS messages in Thunderbird over XMPP to cell bridge via JMP.chat. It sure would be nice to have OMEMO in Thunderbird for my contacts that actually use XMPP, rather than receiving a scrambled message, bc I have OMEMO enabled for them in Conversations, Snikket, Cheogram, BeagleIM, and Gajim and they have it enabled for me.

@msdosfx, where is the bounty? I’d love to add to it.

I have recently been struck by this issue too and would love to support it to have it implemented ASAP.

(In reply to matija from comment #25)

@msdosfx, where is the bounty? I’d love to add to it.

I have recently been struck by this issue too and would love to support it to have it implemented ASAP.

I can't remember. I thought the bounty was here, or at "Are We OMEMO yet?" https://omemo.top/ but I don't see it. maybe it was on bountysource. If I find it, I will post.

(In reply to msdosfx from comment #26)

(In reply to matija from comment #25)

@msdosfx, where is the bounty? I’d love to add to it.

I have recently been struck by this issue too and would love to support it to have it implemented ASAP.

I can't remember. I thought the bounty was here, or at "Are We OMEMO yet?" https://omemo.top/ but I don't see it. maybe it was on bountysource. If I find it, I will post.

A good many clients have implemented OMEMO per https://omemo.top/. Is there something that can be levered from these?

I was unable to find reference anywhere to a bounty. And bountysource is gone.

Perhaps someone could submit a pull request at https://omemo.top/#have-something-to-add--update to change the Thunderbird doc to https://developer.thunderbird.net/thunderbird-development/codebase-overview/chat ?

URL: https://xmpp.org/extensions/xep-0384....
Depends on: 1699091
See Also: → 1909445, https://connect.mozilla.org/t5/ideas/omemo-encryption-for-xmpp-messages/idi-p/31548
No longer depends on: 1699091

(In reply to Wayne Mery (:wsmwk) from comment #28)

A good many clients have implemented OMEMO per https://omemo.top/. Is there something that can be levered from these?

It has been a while since I looked, but several years ago I didn't really find any OMEMO libraries which were separate from an application in a language we could leverage (which would probably be JavaScript/C/C++/Rust) in an appropriate license (MPL/MIT/Apache/LGPL). If folks have any suggestions then that would be appreciated.

(In reply to INTP from comment #24)

This is still an in-demand feature request: https://connect.mozilla.org/t5/ideas/omemo-encryption-for-xmpp-messages/idi-p/31548

Indeed the response at https://connect.mozilla.org/t5/ideas/omemo-encryption-for-xmpp-messages/idi-p/31548 is significant, given the modest size of the chat user population per https://stats.thunderbird.net/#telemetry (though the data there seems incomplete). And OMEMO is important for XMPP given the state of Bug 1909445 - Consider to turn off OTR chat encryption in Thunderbird - because OTRv4 is not making progress. However, OMEMO is not on the Thunderbird Desktop developer roadmap for 2026. So we'd likely be looking for volunteers to implement OMEMO, or help pave the way

Some potentially useful libraries I've found over time:

From what I can tell from https://wiki.xmpp.org/web/Tech_pages/OMEMO, we would ideally want to support both siacs as well as the newer OMEMO:1/OMEMO:2 protocols, but I haven't found a good source for compatibility.

tl;dr I haven't found any libraries which suit our needs.

OMEMO should be bit-compatible with libsignal and in turn libolm and vodozemac - especially in vodozemac's interolm mode: https://github.com/matrix-org/vodozemac/pull/124

(In reply to Matthew Hodgson from comment #32)

OMEMO should be bit-compatible with libsignal and in turn libolm and vodozemac - especially in vodozemac's interolm mode: https://github.com/matrix-org/vodozemac/pull/124

I had talked to Denis (one of the vodozemac) maintainers about this and he said he’d maybe be up for including it after the Signal pieces were merged. I think it just has slightly different serialization/constants from Signal. Not sure if that will happen or not though.

https://codeberg.org/mellium/omemo but has BSD2 license

There's a Rust library that is licensed under the MPL: https://xmpp.rs

(In reply to Râu Cao from comment #35)

There's a Rust library that is licensed under the MPL: https://xmpp.rs

Never mind, I missed that there's no complete and modern OMEMO implementation included.

You need to log in before you can comment on or make changes to this bug.