Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

XEP-0384: OMEMO Encryption #9

Closed
tristan-k opened this issue Feb 11, 2016 · 71 comments
Closed

XEP-0384: OMEMO Encryption #9

tristan-k opened this issue Feb 11, 2016 · 71 comments

Comments

@tristan-k
Copy link

@tristan-k tristan-k commented Feb 11, 2016

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.

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

@therob84 therob84 mentioned this issue Apr 10, 2016
Closed
@therob84
Copy link

@therob84 therob84 commented Apr 10, 2016

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

@apokharel
Copy link
Contributor

@apokharel apokharel commented Apr 10, 2016

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

@therob84
Copy link

@therob84 therob84 commented Apr 10, 2016

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
Copy link

@chrisballinger chrisballinger commented Apr 10, 2016

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
Copy link
Owner

@anurodhp anurodhp commented Apr 10, 2016

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
Copy link

@iNPUTmice iNPUTmice commented Apr 10, 2016

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
Copy link

@chrisballinger chrisballinger commented Apr 10, 2016

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
Copy link

@therob84 therob84 commented Apr 11, 2016

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 (#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
Copy link

@herbsmn herbsmn commented Apr 13, 2016

This thread is awesome. Exciting stuff!

@herbsmn
Copy link

@herbsmn herbsmn commented Apr 13, 2016

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
Copy link
Owner

@anurodhp anurodhp commented Apr 13, 2016

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
Copy link

@iNPUTmice iNPUTmice commented Apr 13, 2016

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
Copy link

@SafwatHalaby SafwatHalaby commented Apr 24, 2016

Days like this I really dislike the gpl.

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

@ara4n
Copy link

@ara4n ara4n commented May 14, 2016

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
Copy link

@herbsmn herbsmn commented May 24, 2016

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
Copy link

@iNPUTmice iNPUTmice commented May 25, 2016

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
Copy link
Owner

@anurodhp anurodhp commented May 25, 2016

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
Copy link

@ara4n ara4n commented May 25, 2016

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
Copy link

@iNPUTmice iNPUTmice commented Jun 3, 2016

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
Copy link

@masvil masvil commented Jun 11, 2016

ChatSecure & Zom are moving to Olm by Matrix.

@iNPUTmice
Copy link

@iNPUTmice iNPUTmice commented Jun 13, 2016

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

@chrisballinger
Copy link

@chrisballinger chrisballinger commented Jun 13, 2016

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
Copy link

@skyfox675 skyfox675 commented Aug 4, 2016

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

@marmistrz
Copy link
Contributor

@marmistrz marmistrz commented Feb 20, 2018

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
Copy link

@chrisballinger chrisballinger commented Feb 20, 2018

@marmistrz
Copy link
Contributor

@marmistrz marmistrz commented Feb 20, 2018

Why?

@anurodhp
Copy link
Owner

@anurodhp anurodhp commented May 10, 2018

@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

@chrisballinger
Copy link

@chrisballinger chrisballinger commented May 10, 2018

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

@anurodhp
Copy link
Owner

@anurodhp anurodhp commented May 10, 2018

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.

@anurodhp
Copy link
Owner

@anurodhp anurodhp commented May 10, 2018

@chrisballinger I am currently spiking it out to understand the protocol better. You can see me tinkering with it here

SignalAddress *address = [[SignalAddress alloc] initWithName:messageNode.from deviceId:messageNode.sid.integerValue];

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

@anurodhp
Copy link
Owner

@anurodhp anurodhp commented May 11, 2018

It's really odd. ill try reproducing my tests on chat secure in the simulator. @chrisballinger are you on xmpp, add me anurodhp@jabb3r.org

@anurodhp
Copy link
Owner

@anurodhp anurodhp commented Jun 12, 2018

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

@Echolon
Copy link
Collaborator

@Echolon Echolon commented Sep 12, 2018

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.

@dholl
Copy link

@dholl dholl commented Nov 24, 2018

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

@dholl
Copy link

@dholl dholl commented Nov 29, 2018

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

@dholl
Copy link

@dholl dholl commented Nov 29, 2018

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!

@anurodhp
Copy link
Owner

@anurodhp anurodhp commented Nov 29, 2018

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 .

@anurodhp anurodhp closed this Nov 29, 2018
@anurodhp
Copy link
Owner

@anurodhp anurodhp commented Nov 29, 2018

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

@benjaminbischoff
Copy link

@benjaminbischoff benjaminbischoff commented Nov 29, 2018

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

@anurodhp
Copy link
Owner

@anurodhp anurodhp commented Nov 29, 2018

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

@dholl
Copy link

@dholl dholl commented Nov 30, 2018

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.

@jelmer
Copy link

@jelmer jelmer commented Jan 5, 2019

Is there a bug tracking the OMEMO support on iOS?

@anurodhp
Copy link
Owner

@anurodhp anurodhp commented Jan 5, 2019

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

@Echolon Echolon changed the title XEP-xxxx: OMEMO Encryption XEP-0384: OMEMO Encryption Jan 23, 2020
@Echolon
Copy link
Collaborator

@Echolon Echolon commented Aug 19, 2020

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!

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
You can’t perform that action at this time.