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.

[SafwatHalaby]

Days like this I really dislike the gpl.

Offtopic food for thought; Should that dislike be directed toward GPL or toward Apple policy?

[ara4n]

I'm a bit late to this one (speaking as the project lead ar matrix.org), but: the constants in Olm's protocol are deliberately chosen to be different to what-was-Axolotl, with the intention of changing them if OWS was ever happy to federate. Otherwise the protocol should in theory be directly compatible with Axolotl v2 - unsure about v3, but changing the prekey signing behaviour is easy enough. It is awesome to see the XMPP community finding use in Olm, and we would love for the resulting E2E to be interoperable between both XMPP, Matrix, Wire, Signal, and anywhere else axolotl derivates are used. I would strongly suggest not changing Olm's constants for the sake of it, as it will only make eventual interop unnecessarily harder :)

[herbsmn]

This seems like a good place to ping everyone about this Pidgin inquiry about OMEMO. Let me know if the conversation has moved elsewhere. https://developer.pidgin.im/ticket/16801#comment:16

[iNPUTmice]

Hi,

sorry @apokharel for abusing your issue tracker this way but this issue has become some sort of central place that is being referenced from referenced from elsewhere.

I can only recommend to any client that is licensed under the GPL and has an actual interest in OMEMO to start now and just use the libsignal-protocol (former libaxolotl). What kind of crypto library is being used only makes about 10% of the entire OMEMO code anyway. If we as a community at some point switch to something olm based it is probably going to be a drop in replacement code wise. Meaning you would basically just replace all libsignal.doSomething with libolm.doSomething. 90% of the work on OMEMO is on the XMPP and the UI side of things.

As a client developer you have nothing to loose by using libsignal-protocol for your OMEMO implementation. On the contrary you have two clients (Conversations and Gajim) to test your code with.

Yes offering an alternative to libsignal-protocol that might or might not be libolm is a longterm goal but it's not something worth waiting for if you can legally use libsignal-protocol (meaning if your client is GPL)

[anurodhp]

It's good that all of us are discussing this here. At the end of the day the clients we make are what most people are is going to experience XMPP as and we all need to be on the same boat.

The GPL is a non starter for anything on iOS due to the presence of DRM in App Store signed binaries. Even though the code is open source and a user can side load apps on an iOS device without restrictions, from everything I know, its incompatible with the political aims of the GPL. Additionally Monal is BSD licensed, which I believe is incompatible with the GPL. Chat secure itself is GPL3+ but that doesn't let @chrisballinger actually use GPL code someone else wrote without it being relicensed.

The saga of VLC on iOS is worth noting: http://arstechnica.com/apple/2011/01/vlc-for-ios-vanishes-2-months-after-eruption-of-gpl-dispute/ http://arstechnica.com/apple/2013/07/vlc-media-player-returns-to-the-ios-app-store-after-30-month-hiatus/

[ara4n]

As a general heads up: work on Olm is progressingly rapidly at the moment (http://matrix.org/git/olm/log/) after a hiatus of several months - we've just added group ratchet semantics on top (named megolm), and made a bunch of improvements to the olm layer too. I'm not sure if anyone's interested in using the group shared-ratchet semantics, but they should be a significant improvement over axolotl/signal in terms of support for optionally sharing/replaying history. We're also getting ready to get the lib formally audited at some point in the next few months. Finally, we're hoping to start using it in anger in Matrix in the relatively near future. Hopefully all this combines to make Olm an interesting proposition for folks seeking a permissive-licensed ratchet implementation. We're always around and available to discuss at https://matrix.to/#/#matrix-dev:matrix.org if anyone has questions (XMPP bridges welcome :)

[iNPUTmice]

The GPL is a non starter for anything on iOS due to the presence of DRM in App Store signed binaries.

This is correct. However @moxie0 repeatedly told people that he has no problem with a GPL licensed client using libsignalprotocol to be published on the App Store. That's why I'm encouraging developers to just go ahead and start implementing it if their client is GPL. Moxie is apparently looking into formalizing that exemption. (He already gave his consent on various places all around the internet; Hackernews, Twitter, Github.). A formal exemption probably just takes time because lawyers or what ever.

If this for some reason fails there is still:

What kind of crypto library is being used only makes about 10% of the entire OMEMO code anyway. If we as a community at some point switch to something olm based it is probably going to be a drop in replacement code wise. Meaning you would basically just replace all libsignal.doSomething with libolm.doSomething. 90% of the work on OMEMO is on the XMPP and the UI side of things.

which can act as a fallback solution.

[masvil]

ChatSecure & Zom are moving to Olm by Matrix.

[iNPUTmice]

And here it is in writing. On their blog and on github.

[chrisballinger]

So this new development might mean we are moving forward with libsignal-protocol-c. This doesn't rule out supporting Olm in the future as well, which could also be useful for XMPP/Matrix bridges, and interoperability with other non-GPL apps.

[skyfox675]

I would really like to see this implemented! Hope this continues :+1:

[herbsmn]

since the signal protocol licence was changed, monal can move forward with this now, no?

[chrisballinger]

It's GPL with an additional App Store permission, so Monal would need to switch over to GPL, at least when shipping any OMEMO code. In ChatSecure we will probably put it behind an ifdef so we can provide unencumbered code as well.

On Wed, Sep 7, 2016 at 5:21 PM, herbsmn notifications@github.com wrote:

since the signal protocol licence was changed, monal can move forward with this now, no?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/anurodhp/Monal/issues/9#issuecomment-245459312, or mute the thread https://github.com/notifications/unsubscribe-auth/AAfqH9t0hik5_aB5306OvcUtW1FzzpOGks5qn1UEgaJpZM4HYI_N .

[GreenLunar]

What is an ifdef?

[intelfx]

@GreenLunar http://lmgtfy.com/?q=ifdef

[GreenLunar]

@intelfx, is this a joke? (please delete your comment too)

I have looked up for it, and my question remains.

What is an ifdef, in this thread's context?

[bascht]

@GreenLunar Monal is BSD-2-Clause licensed. The Signal bits are GPL licensed, so i think ifdefs in that context would mean that you'd have the chance to flick a switch before compilation, and choose to get a BSD licensed binary (without libsignal) or a GPL+Appstore licensed binary (with libsignal).

Somebody correct me if I'm wrong. ;)

[ghost]

@GreenLunar: #ifdef is a preprocessor directive used to enable (or disable) segments & files of code during the build process.

Take a look a the GNU build system. Other systems support it too as a C Preprocessor is expected.

What @intelfx is saying, is that this is a trivial information and finding out for your self would have probably taken a single search.

[GreenLunar]

I am a type of person that checks deep into new things, and so I likely to interpret a new term in several ways that do not correspond with this context.

Anyhow, @intelfx could have write down the same answer you just gave, not referring to (what I consider as) a prank website and expecting me, by this implication, to get a clue of what his answer might mean.

P.S. thank you for the elaboration!

[zzzzzzzzzzzzzzzzzzzzzzzzzzz]

Please, make support OTR

[Quintus]

Please come back to topic. So what we got now is a GPL library with an exception for publishing on the Apple Store. The situation thus is basically the same as before: non-gpl XMPP clients are not possible, which hurts XMPP as a whole. Even worse, we are about to move to a protocol that is not documented anywhere or even formerly standardised; the entire XMPP community is about to make itself dependant from a single implementation of an undocumented protocol. So the first thing to strive for should really be a formal specification or at least documentation of the Axolotl double rachet (or however it is currently called). Are there any serious efforts to do that?

Greetings Marvin

[ara4n]

yup, the Olm implementation is formally specified: https://matrix.org/docs/spec/olm.html and the implementation (Apache licensed) is currently in the middle of a public crypto audit whose results will be published. We've also just finished a similar formal specification for the Megolm group ratchet that the library also applies which we use in Matrix, in case anyone wants to use it in XMPPland: http://faith.sw1v.org/~rav/olm/megolm.html. Neither ratchet is specific to Matrix; it's just a ratchet library.

[Quintus]

Very nice. Thank you very much! Let's hope that the official OMEMO XEP will then refer to that specification. Back in December 2015, it was at least brought up on the standard mailinglist: https://mail.jabber.org/pipermail/standards/2015-December/030727.html and then repeated and positively regarded in April 2016: https://mail.jabber.org/pipermail/standards/2016-April/031032.html . Since then, nothing more has happened around the OMEMO specification.

Anybody willing to rewrite http://xmpp.org/extensions/inbox/omemo.html with olm and submit that to the standards people? As of now, it still says Axolotl v3.

Greetings Marvin

[SamWhited]

Anybody willing to rewrite http://xmpp.org/extensions/inbox/omemo.html with olm and submit that to the standards people? As of now, it still says Axolotl v3.

There is an open PR for this and @iNPUTmice and I have been discussing the specifics. Work is ongoing.

[Quintus]

On Tue, Sep 27, 2016 at 12:15:23PM -0700, Sam Whited wrote:

There is an open PR for this and @iNPUTmice and I have been discussing the specifics. Work is ongoing.

Great! Do you have a link?

Greetings Marvin

Blog: http://www.guelkerdev.de PGP/GPG ID: F1D8799FBCC8BC4F

[ara4n]

I'd missed @dwd's comment on the ML in April. For the record, olm is intended to be very easily compatible with axolotl v2, although we haven't tested it - and the differences with axolotl v3 are minor; signing prekeys iirc, which can also be mitigated at the application layer if needed. theoretically the biggest difference (from memory) is that the two impls use different constants to initially seed the key derivation function.

[herbsmn]

Here's some links @Quintus https://github.com/xsf/xeps/blob/master/inbox/omemo.xml https://github.com/xsf/xeps/blob/master/inbox/omemo-filetransfer.xml https://github.com/xsf/xeps/pull/251

[dwd]

Ah, okay, I think I thought it was v3, with different IVs, @ara4n - we thought you'd changed the IV for legal reasons, is that the case? It's useful to know if this is really the case.

[ara4n]

I'm not sure v3 is particularly well specified anywhere, although i remember reading somewhere that the main difference is signed prekeys. Olm doesn't try to be v2 or v3 per se but its own thing with its own IVs, albeit using the same pattern as the original axolotl spec sketch and being similar enough to easily compatibility with Signal if ever desired. As per the comments above, we currently deliberately don't sign prekeys on the misunderstanding that this poses more problems than it solves; however I strongly suspect this will change next week.

(hah - i'm an idiot; i wrote this by email and thought i was responding to the https://github.com/xsf/xeps/pull/251 thread. the sentiment still stands though!)

[bawlsout]

Is there needed an exception for play store?

[ara4n]

Olm is apache licensed and entirely compatible with apple & play stores. No exceptions needed.

[Loader23]

Omemo does have an XEP Number now: http://www.xmpp.org/extensions/xep-0384.html

Please implement it soon :-)

[librilex]

Has there been made any progress in implementing XEP-0384 in Monal? I hope it will be integrated soon, that would be really great!

[chrisballinger]

I think the main blocker is that there are no permissively licensed X3DH libraries yet.

On Wed, Apr 19, 2017 at 2:46 PM, librilex notifications@github.com wrote:

Has there been any progress made in implementing XEP-0384 in Monal? I hope it will be integrated soon, that would be really great!

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/anurodhp/Monal/issues/9#issuecomment-295457956, or mute the thread https://github.com/notifications/unsubscribe-auth/AAfqH4ocJzggsDwQ5vahm4m1ADc_V4n9ks5rxoC3gaJpZM4HYI_N .

[ara4n]

As per https://mail.jabber.org/pipermail/standards/2017-March/032551.html i'm very confused and have yet to hear a good explanation of why you'd want X3DH...

[chrisballinger]

As of right now I don't think anyone is running OMEMO w/ the official namespace, and are just using the legacy Conversations one w/ X3DH. Although we figured out a GPL-friendly solution to use libsignal-protocol-c, I'd welcome the usage of Olm because of its permissive nature. :)

[marmistrz]

Sorry if it's already been answered in the wall of comments - can't you just ask Apple to make an exception for you and disable DRM for your app?

[chrisballinger]

@marmistrz No.