XEP-0384: OMEMO Encryption about monal HOT 71 CLOSED

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

Please implement it soon :-)

from monal.

Days like this I really dislike the gpl.

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

from monal.

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!

from monal.

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)

from monal.

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

from monal.

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

from monal.

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.

from monal.

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 :)

from monal.

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.

from monal.

ChatSecure & Zom are moving to Olm by Matrix.

from monal.

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.

from monal.

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.

from monal.

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.

from monal.

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/

from monal.

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

from monal.

@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?

from monal.

Please, make support OTR

from monal.

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

from monal.

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.

from monal.

Sweet! https://monal.im/blog/ios-has-omemo-working/

from monal.

Shouldnt it be shown somehow, that a message is (OMEMO) encrypted. However - I suggest to just show the user that is encrypted and only give details about it in a hidden menu or so. Because most even cannot explain what encryption itself is.

from monal.

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

from monal.

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

from monal.

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!

from monal.

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

from monal.

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

from monal.

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
xsf/xeps#251

from monal.

Why?

from monal.

Or perhaps a small green padlock or check-mark somewhere near each message? (and if a message is unencrypted, perhaps a small gray unlocked padlock or a gray x-mark?)

from monal.

It’s actually in both clients , I’m just keeping it out of iOS releases since that has a different audience .

So the actual iOS version has the OMEMO feature (to read encrypted messages) not yet enabled?, that would explain why it will not work ....
And I think with the start of Conversations and Quicksy more people would like to chat with iOS-people ..., and therefore they will need OMEMO ;)

from monal.

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.

from monal.

This thread is awesome. Exciting stuff!

from monal.

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.

from monal.

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.

from monal.

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

from monal.

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 :)

from monal.

I would really like to see this implemented! Hope this continues 👍

from monal.

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

from monal.

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 [email protected] 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
.

from monal.

What is an ifdef?

from monal.

@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. ;)

from monal.

@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.

from monal.

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!

from monal.

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

from monal.

from monal.

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.

from monal.

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 xsf/xeps#251 thread. the sentiment still stands though!)

from monal.

Is there needed an exception for play store?

from monal.

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

from monal.

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

from monal.

from monal.

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...

from monal.

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. :)

from monal.

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?

from monal.

@marmistrz No.

from monal.

@chrisballinger So, I am looking at the cocoa pod you have published for omemo, assuming that it is a good idea for the two main iOS clients and my Mac client to all share the same code. I am not able to actually get it decode the keys that gajim is sending it. It looks like an issue with the protobuf prior to even decrypting the message field in the protobuf. The things that Daniel sent me also do not decode, I dont know where the error is or if there is a step that isn't documented that I am missing when dealing with key data on a message.

As a test im curious to see if you are able to decode any of the base64 protobuf strings using protoc --decode_raw or this tool online: https://protogen.marcgravell.com/decode

from monal.

@anurodhp Glad to hear you're joining the OMEMO fold! It would be great to have Monal support OMEMO so we can finally have a native macOS client :) I've never tested with Gajim, only with Conversations and Zom, and a few times with Dino. I'd be happy to take a look at your code if it's in a branch somewhere.

Are you referring to our work on XMPPFramework's OMEMOModule? Or SignalProtocol-ObjC?

from monal.

I’m looking at the signalprotocol objective-c. Gajim can talk to chat secure, I’ve tested it. I’m trying to understand what the proto buf is doing. Could you try looking at one of your base 64 key strings? My errors are protobuf related prior to and decryption.

from monal.

@chrisballinger I am currently spiking it out to understand the protocol better. You can see me tinkering with it here https://github.com/anurodhp/Monal/blob/988cbc207a65bd013a81d4208405a4b6a9c1807b/Monal/Classes/xmpp.m#L1687

decryptciphertext fails at 1708 with an invalid protobuffer, so it never actually gets as far as extracting the encrypted key from the signal message.

from monal.

Hmm. Can't tell from looking at it. Have you looked at the usage example of SignalProtocolObjC in ChatSecure?

• https://github.com/ChatSecure/ChatSecure-iOS/blob/master/ChatSecure/Classes/Controllers/OTRAccountSignalEncryptionManager.swift
• https://github.com/ChatSecure/ChatSecure-iOS/blob/master/ChatSecure/Classes/Controllers/OTROMEMOSignalCoordinator.swift

These may be useful as well for the base64/xmpp/xml portion:

• https://github.com/robbiehanson/XMPPFramework/tree/master/Extensions/OMEMO
• https://github.com/robbiehanson/XMPPFramework/blob/master/Extensions/OMEMO/NSXMLElement+OMEMO.m
• https://github.com/robbiehanson/XMPPFramework/blob/master/Extensions/OMEMO/XMPPIQ%2BOMEMO.m
• https://github.com/robbiehanson/XMPPFramework/blob/master/Extensions/OMEMO/XMPPMessage%2BOMEMO.m

from monal.

It's really odd. ill try reproducing my tests on chat secure in the simulator. @chrisballinger are you on xmpp, add me [email protected]

from monal.

@chrisballinger I'll be sending your a PR for a change I made to your code to get it to work when using the cocoa pod.

My mistake was passing the key NSdata in my implementation of the store and not using the serialize method.

Unrelated, fixing AES to GCM-128 helped a lot.. :)

https://monal.im/blog/update-on-omemo-2/

from monal.

Ahh, I found the Monal beta release... :) I like the little lock icon next to the memo messages.

from monal.

So.... Since Monal beta has OMEMO, when does this issue get closed?

Specifically, I'd like to report a new OMEMO-related issue that I didn't see in the tracker, and I'm wondering: Should I included it here in this issue? Or should I create a new separate issue?

I'm using both Conversations (on phone) and Monal beta (on laptop, downloaded an hour ago, "Version 2.2 (96)"). When I send a message with Conversations to another contact, Monal can also see what I sent, because Conversations encrypted the message for both the destination contact, as well as for Monal running on my laptop. But when I send a message with Monal, only my contact can see it, and on Conversations, I only see a message from me saying "Message was not encrypted for this device." So, I take it that Monal isn't including my other OMEMO keys as well.

So, I'm wondering if I should create a new issue to request support for encrypting to my other devices. And if @anurodhp suspects this could be an opportunity for a contribution, I'm game for trying to add this support myself. (I'm just unfamiliar with Monal's code, but I'm game to get up to speed and help out if my contributions would be helpful and welcome.)

Thank you!

from monal.

It’s actually in both clients , I’m just keeping it out of iOS releases since that has a different audience . Let’s close this. The whole reason the Mac beta is out is to find bugs, please file that as a new bug and I’ll fix it .

from monal.

Also you are always welcome to look at the code and tinker. If you fix anything send over a pull request

from monal.

Yeah I’m working out al the logic bugs in the Mac betas. Please bang at it and submit bugs. I need to make the ui fornkey inspection and trust. It’s coming soon

from monal.

It’s actually in both clients , I’m just keeping it out of iOS releases since that has a different audience . Let’s close this. The whole reason the Mac beta is out is to find bugs, please file that as a new bug and I’ll fix it .

Also you are always welcome to look at the code and tinker. If you fix anything send over a pull request

Thank you! Will do.

from monal.

Is there a bug tracking the OMEMO support on iOS?

from monal.

The Mac and iOS apps are the same thing and have the same bugs. If there are any specific issues just file a new bug for that issue

from monal.

Dear discussion participants,

I post this here because the next Monal update is upcoming. We introduced many changes to the back-end and we want to ensure usability and quality. Therefore we call for testers of the also upcoming beta on Testflight. So, even we cannot guarantee all issues has been fixed or considered yet we ask for your help!

• Monal blog
• Support Monal
• Translations on Weblate
• Public group chat: [email protected]

We really appreciate your help and are looking forward to a better establishment of XMPP on iOS and Mac!

from monal.