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-xxxx: OMEMO Encryption #9

Open
tristan-k opened this Issue Feb 11, 2016 · 60 comments

Comments

Projects
None yet
@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 referenced this issue Apr 10, 2016

Closed

Otr #28

@therob84

This comment has been minimized.

Show comment
Hide comment
@therob84

therob84 Apr 10, 2016

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

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

This comment has been minimized.

Show comment
Hide comment
@apokharel

apokharel Apr 10, 2016

Contributor

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

Contributor

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

This comment has been minimized.

Show comment
Hide comment
@therob84

therob84 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!

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

This comment has been minimized.

Show comment
Hide comment
@chrisballinger

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

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

This comment has been minimized.

Show comment
Hide comment
@anurodhp

anurodhp Apr 10, 2016

Owner

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.

Owner

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

This comment has been minimized.

Show comment
Hide comment
@iNPUTmice

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

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

This comment has been minimized.

Show comment
Hide comment
@chrisballinger

chrisballinger 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!

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

This comment has been minimized.

Show comment
Hide comment
@therob84

therob84 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

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

This comment has been minimized.

Show comment
Hide comment
@herbsmn

herbsmn Apr 13, 2016

This thread is awesome. Exciting stuff!

herbsmn commented Apr 13, 2016

This thread is awesome. Exciting stuff!

@herbsmn

This comment has been minimized.

Show comment
Hide comment
@herbsmn

herbsmn 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

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

This comment has been minimized.

Show comment
Hide comment
@anurodhp

anurodhp Apr 13, 2016

Owner

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.

Owner

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

This comment has been minimized.

Show comment
Hide comment
@iNPUTmice

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

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

This comment has been minimized.

Show comment
Hide comment
@SafwatHalaby

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

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

This comment has been minimized.

Show comment
Hide comment
@ara4n

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

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

This comment has been minimized.

Show comment
Hide comment
@herbsmn

herbsmn 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

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

This comment has been minimized.

Show comment
Hide comment
@iNPUTmice

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

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

This comment has been minimized.

Show comment
Hide comment
@anurodhp

anurodhp May 25, 2016

Owner

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/

Owner

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

This comment has been minimized.

Show comment
Hide comment
@ara4n

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

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

This comment has been minimized.

Show comment
Hide comment
@iNPUTmice

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

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

This comment has been minimized.

Show comment
Hide comment
@masvil

masvil commented Jun 11, 2016

ChatSecure & Zom are moving to Olm by Matrix.

@iNPUTmice

This comment has been minimized.

Show comment
Hide comment
@iNPUTmice

iNPUTmice Jun 13, 2016

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

iNPUTmice commented Jun 13, 2016

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

@chrisballinger

This comment has been minimized.

Show comment
Hide comment
@chrisballinger

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

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

This comment has been minimized.

Show comment
Hide comment
@skyfox675

skyfox675 Aug 4, 2016

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

skyfox675 commented Aug 4, 2016

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

@ara4n

This comment has been minimized.

Show comment
Hide comment
@ara4n

ara4n Sep 27, 2016

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.

ara4n commented Sep 27, 2016

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

This comment has been minimized.

Show comment
Hide comment
@Quintus

Quintus Sep 27, 2016

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

Quintus commented Sep 27, 2016

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

This comment has been minimized.

Show comment
Hide comment
@SamWhited

SamWhited Sep 27, 2016

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.

SamWhited commented Sep 27, 2016

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

This comment has been minimized.

Show comment
Hide comment
@Quintus

Quintus Sep 27, 2016

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

Quintus commented Sep 27, 2016

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

This comment has been minimized.

Show comment
Hide comment
@ara4n

ara4n Sep 27, 2016

ara4n commented Sep 27, 2016

@dwd

This comment has been minimized.

Show comment
Hide comment
@dwd

dwd Oct 6, 2016

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.

dwd commented Oct 6, 2016

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

This comment has been minimized.

Show comment
Hide comment
@ara4n

ara4n Oct 6, 2016

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

ara4n commented Oct 6, 2016

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

@bawlsout

This comment has been minimized.

Show comment
Hide comment
@bawlsout

bawlsout Oct 16, 2016

Is there needed an exception for play store?

bawlsout commented Oct 16, 2016

Is there needed an exception for play store?

@ara4n

This comment has been minimized.

Show comment
Hide comment
@ara4n

ara4n Oct 16, 2016

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

ara4n commented Oct 16, 2016

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

@Loader23

This comment has been minimized.

Show comment
Hide comment
@Loader23

Loader23 Dec 21, 2016

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

Please implement it soon :-)

Loader23 commented Dec 21, 2016

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

Please implement it soon :-)

@librilex

This comment has been minimized.

Show comment
Hide comment
@librilex

librilex Apr 19, 2017

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

librilex commented Apr 19, 2017

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

This comment has been minimized.

Show comment
Hide comment
@chrisballinger

chrisballinger Apr 19, 2017

chrisballinger commented Apr 19, 2017

@ara4n

This comment has been minimized.

Show comment
Hide comment
@ara4n

ara4n Apr 19, 2017

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

ara4n commented Apr 19, 2017

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

This comment has been minimized.

Show comment
Hide comment
@chrisballinger

chrisballinger Apr 20, 2017

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

chrisballinger commented Apr 20, 2017

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

This comment has been minimized.

Show comment
Hide comment
@marmistrz

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

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

This comment has been minimized.

Show comment
Hide comment
@chrisballinger

chrisballinger commented Feb 20, 2018

@marmistrz

This comment has been minimized.

Show comment
Hide comment
@marmistrz

marmistrz commented Feb 20, 2018

Why?

@anurodhp

This comment has been minimized.

Show comment
Hide comment
@anurodhp

anurodhp May 10, 2018

Owner

@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

Owner

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

This comment has been minimized.

Show comment
Hide comment
@chrisballinger

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

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

This comment has been minimized.

Show comment
Hide comment
@anurodhp

anurodhp May 10, 2018

Owner

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.

Owner

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

This comment has been minimized.

Show comment
Hide comment
@anurodhp

anurodhp May 10, 2018

Owner

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

Owner

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.

@chrisballinger
@anurodhp

This comment has been minimized.

Show comment
Hide comment
@anurodhp

anurodhp May 11, 2018

Owner

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

Owner

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

This comment has been minimized.

Show comment
Hide comment
@anurodhp

anurodhp Jun 12, 2018

Owner

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

Owner

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/

@herbsmn

This comment has been minimized.

Show comment
Hide comment

herbsmn commented Sep 9, 2018

@Echolon

This comment has been minimized.

Show comment
Hide comment
@Echolon

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

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment