XEP-0384: OMEMO Encryption

[tristan-k]

OMEMO is an XMPP Extension Protocol (XEP) for secure multi-client end-to-end encryption. It is an open standard based on Axolotl and PEP which can be freely used and implemented by anyone.

• https://xmpp.org/extensions/inbox/omemo.html
• https://conversations.im/xeps/multi-end.html

For further reading on an iOS implemention, see this report about ChatSecure status on OMEMO.

[therob84]

+1
to support this perfect working encryption method OMEMO to not leave WhatsApp & Co the market alone! (connected to #28)

[apokharel]

Yeah, i started by looking at OTR but it really doesn't look like the right choice here esp with carbons and MAM

[therob84]

I can strongly support the idea of dropping work of OTR and recommend putting all effort to integrate OMEMO, as it really works flawless in Conversations at Android and still needs a strong teammate on iOS, which Monal or ChatSecure should become as fast as possible!

[chrisballinger]

It is impossible to implement OMEMO on iOS due to the current license restrictions around AxolotlV3/SignalProtocol. OMEMO is based around the AxolotlV3 protocol from libaxolotl-java, which has no publicly available specification. Currently the only libraries provided are GPL licensed which cannot be distributed on the App Store by others without a specific exemption.

Moxie told me that by reading the source code, any attempt at an independent implementation will be a derivative work, and also under the GPL. He also mentioned there are no plans to relicense this code to others (except to WhatsApp, I guess), and that a public specification won't be available for a long time.

The Axolotl ratchet itself, now renamed "double ratchet", has a public domain spec but alone it is very generic and not enough to implement something compatible with the SignalProtocol libraries. The only legally permissible ways to distribute async-friendly crypto on the App Store is to write your own library from scratch that is incompatible with AxolotlV3 and thus OMEMO. There are some alternative ratchet implementations under Apache 2.0, olm written by the matrix.org team, and zina written by Silent Circle. They are incompatible with each other, and also incompatible with AxolotlV3, but they could potentially be used to build a tweaked version of something like OMEMO... that would be incompatible with existing OMEMO clients.

I've been toying with an Objective-C wrapper for Olm under the provisional name OLMKit. At this point I have most of Olm's C API wrapped, and I have some rudimentary tests for message encryption / decryption.

The last, possibly insane, option would be to hire an independent 3rd party to write a full specification of the AxolotlV3 protocol, and then write your own clean-room implementation without consulting the original source code.

[anurodhp]

I didn't know this. That's depressing. I can understand why what's app would be exempted but it still sucks. Days like this I really dislike the gpl.

[iNPUTmice]

Hi Chris,

good write up of the current situation. I think the way to go here is to specify and then implement a revised version of OMEMO based on the OLM protocol (which is pretty similar to what the axolotl protocol v2 looked like.)

The OLM protocol has some hard coded strings in it that don't hurt but aren't really necessary. I imagine that we can copy the OLM spec for the most part and integrate it into the OMEMO spec.

If we go through with this this will also give us the chance to rethink the wire format. (Axolotl v2 and OLM while doing basically the same thing use different wire formats.) By making OMEMO a full spec that doesn't just reference another one we have the chance to make our own choices.

[chrisballinger]

I just had a crazy idea to download axolotl.js on first launch and run it via JavaScriptCore to circumvent the GPL issue.. but I really wouldn't want to prove the legality of that in court. :)

I like the simplicity of the Olm library and within a few days I got it to the point where I could start integrating it into ChatSecure. It has some rough edges but the code is reasonably clean and easy to read. Would love to work with you more closely in the upcoming weeks to help figure out a revised spec!

[therob84]

Nice to see that you have some promising ideas to push OMEMO further and started discussion in public, that we users can read about your concerns and progress....

I still hope the best and very welcome the (just) started inter-app-discussion about OMEMO (https://github.com/anurodhp/Monal/issues/9) ... triggering long enaugh from all sides finally lead to the long needed (public visibly) teamwork between you ALL,
@chrisballinger (ChatSecure),
@iNPUTmice (Conversations),
@anurodhp (Monal) .....
Keep on this good work and especially to let us know on what you are working on here!

Cheers, Robert

[herbsmn]

This thread is awesome. Exciting stuff!

[herbsmn]

I just suggested to Tor Messenger and Pidgin that they read this thread and consider waiting to impliment OMEMO until a non-GPL based version comes around. I hope this wasn't a stupid move.

https://developer.pidgin.im/ticket/16801
https://trac.torproject.org/projects/tor/ticket/17457

[anurodhp]

Given that pidgin is GPL, i don't think they will have any issues. What is happening however is that depending on the license of your code (Apache, BSD etc) vs GPL there will be incompatibility when talking to a client with the other license, which is unfortunate. Realistically we should shun a standard that isn't available on some OSes because of a restrictive license.

[iNPUTmice]

It might be worth it for Pidgin to wait for this OMEMO fork to be created

This is not going to be a fork. This is just going to be the next step in the standardization process

If Tor Messenger is going to impliment an encryption protocol like OMEMO, it might be worth it to use the fork that these people are building instead of OMEMO itself so that Tor Messenger users can communicate with iOS users using a Signal based encryption standard. Also, OMEMO was created by the Conversations App person, so it he is transitioning to something else, it might be good to use that instead of OMEMO.

There is no encryption protocol like OMEMO. There is no instead of OMEMO. This is simply going to be OMEMO.