Implement OMEMO (Multi-End Message and Object Encryption)

NEW
Unassigned

Status

3 years ago
5 months ago

People

(Reporter: nikos, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

3 years ago
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)

Comment 1

2 years ago
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.pdfhttps://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?

Comment 2

2 years ago
(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.

Comment 3

2 years ago
Can you explain your second sentence further?

Comment 4

2 years ago
(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.

Comment 5

2 years ago
You could theoretically use the JS implementation of OMEMO....

Comment 6

2 years ago
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

Comment 7

2 years ago
Ok never mind the links above. It's probably easier and cleaner to just make libomemo and axc able to use different crypto backends.

Comment 8

2 years ago
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.

Comment 9

a year ago
any updates on this? I'm really excited about it.

Comment 10

10 months ago
same here. would love to hear an update.

Comment 11

10 months ago
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
You need to log in before you can comment on or make changes to this bug.