Add Omemo Encryption Support

[dreamflasher]

Please add support for the new OMEMO XEP: http://xmpp.org/extensions/xep-0384.html

OMEMO is an XMPP Extension Protocol (XEP) for secure multi-client end-to-end encryption: ​http://conversations.im/omemo/ It offers Forward Secrecy and deniability while allowing you to keep the benefits of message synchronization and offline delivery.

OMEMO uses the Double Ratchet algorithm to establish secure sessions between every combination of devices: ​https://en.wikipedia.org/wiki/OMEMO

It's current support status in other XMPP clients is tracked here: http://www.omemo.top

[Kev]

Thanks for the suggestion. It's something we're considering for the future, but is not currently on the roadmap.

[Kev]

@remko's been having a bit of a look at this recently, and there's ongoing discussion on the mailing lists about the appropriate things for OMEMO to be doing to allow independent implementations, but yes - Swiften and Swift support would be required for this.

[remko]

Nothing new on the Swift side of things.

Maybe some background: OMEMO has not been standardized yet, and isn't quite there yet either. The non-standardized version currently used by other clients cannot be implemented in Swift due to licensing issues. There have been many discussions in the past months on how to get to a version that is broadly implementable, but no agreements have been reached yet. I hope this will change soon. Once things are unblocked there, the protocol still needs to be further discussed and defined (e.g. I think there are still some things missing to improve usability).

Hopefully, by the time the standard is ready for implementation (which nobody knows how long it will take), I will have a Swift implementation ready as well (although I can't promise anything at this point).

[sergeevabc]

“Are we OMEMO yet?” website gives an overview of the status of implementation across XMPP clients.

[tdemin]

@remko hasn't it? It has got its XEP number (XEP-0384) in December 2016.

[dreamflasher]

@remko Yeah, OMEMO is standardized a long time again (see previous comment), the license issues also have been resolved back then, and the protocol is also stable and defined :) The standard is ready for implementation, and a lot of clients have implemented it. www.omemo.top

[h4knet]

Hello,
I'm new to Swift; Is there any news from last year ? ^^
Is it on the roadmap now ?
Where can we find the roadmap ?

[remko]

No news. Nothing has happened on the protocol to address the concerns mentioned before, so nothing has happened on the Swift side either.

[dreamflasher]

That's quite incorrect. As previous comments pointed out everything is good on the Omemo side.

[Kev]

Hi, a bit of an update to the ticket on the standardisation side:
Until recently, the thing that was implemented by clients wasn't what was specified as OMEMO by the XSF, but was something else that also called itself OMEMO - obviously confusing. The XSF decided, as a compromise, to take a two-stage approach OMEMO. Stage 1 was to publish what the current clients implement, so they're able to refer to a particular version of the spec, without resolving the current licensing etc. issues, and stage 2 is to then do the necessary work to update the spec to resolve the current issues (which include, but aren't limited to, licensing). As things stand we're at stage 1, and there's currently no-one who's stepped forward to do the necessary stage 2 work.

So, as Remko says, we're not currently where we need to be for Swift to be implementing it.

[Echolon]

@Kev but as I understand, you are generally willing to implement, once there is a sufficient standardisation, correct?

Cheers

[Kev]

It's not currently a priority for us spending time on, but (once the issues are resolved), we'd be likely to accept a well-crafted patch that added it if someone wanted to make one (in some way that didn't break anything else).

[sergeevabc]

In the age of surveillance, when privacy is trampled daily, when EFF’s founder demise truly saddens and Signal’s ascent is encouraging, at this very time @Kev — without batting an eye — admits Swift’s priority is anything, but not keeping pace with how communication medium should be secured. Then delegates this crucial and sensitive task to the periphery at the mercy of random people. What a staggering vision!

[dwd]

At this time, I'd highly recommend awaiting MLS. Probably won't be a long wait, and it feels very promising to have an Open Standard in this area we can build on instead of using whatever happens to be flavour of the month.

[morgothdidnothingwrong]

Hello,

As you can see in my history, I don't know how to code and I'm not a good contributor. I'm doing my best to improve it anyway !

But @Kev, prior to someone building an OMEMO plugin “without breaking anything else”, they should read your code structure without any specific documentation (AFAIK) and I doubt it will ever happen. Libreoffice has like less than 40 contributors, and although adding OMEMO to Swift would be a cool project, and make one's resume shine a little, I doubt someone will implement the OMEMO protocol – at least for free.

AFAIK, it doesn't only implement encrypted group chat but also encrypted file sharing and offline encryption (against OTR), and I specifically looked for Swift on https://omemo.top because I'd be downloading it now if you had implemented OMEMO. Although I understand that a lot of chat clients already implement this, and that your project may be somewhat different, but I'd like to be part of it without giving up either my contacts or everyone's E2E encryption in the group chat… (It's also worth noting that there's probably someone in the group who specifically uses XMPP for its encryption ! Should they give up the reasons why they're here for 70% of their communications, or just leave the group chat ?)

So if I had the honour of leading such an XMPP client I'd add a bounty on https://bountysource.com, this being said without, I hope, condescension or anything. I just think implementing OMEMO is important, not only for the encryption itself, but for everyone using other clients.

Best regards !

[tuxayo]

@sergeevabc

at this very time @Kev — without batting an eye — admits Swift’s priority is anything, but not keeping pace with how communication medium should be secured. Then delegates this crucial and sensitive task to the periphery at the mercy of random people. What a staggering vision!

This part looks too much reproachful and targeted and thus might not contribute to an healthy discussion about this topic.

[Echolon]

@Kev @remko At least I would suggest to keep the issue open, as lots of people seem to be interested in and the target is, whenever it will be, to still implement it (or?). And people won't start a new issue about it.

[aveao]

Any update on re-opening this issue? You stated that PRs are welcome for this, so it makes sense to actually advertise that fact.

[bernhardreiter]

Ping.
If patches are welcome when the specs are in good enough shape, it seems sensible to keep the issue open.

[bernhardreiter]

@Kev is there a list of issues with the current spec (you mention above)?

What is the licensing issue? The only mention in https://xmpp.org/extensions/xep-0384.html#intro-motivation is that there is one reference implementation under GNU GPL v>=3. Is this what you refer to? It does not seem to be a problem for a new implementation, though. (GNU GPL allows studying the source code to understand the protocol.)

[dwd]

The XSF view has always been that we implement from spec, and not from reverse-engineering the protocol from other implementations. Developers have tried to independently implement OMEMO from scratch, but it's proven impossible from the XEP currently - every extant implementation has been worked on by people associated with the original implementation. So it's not a viable specification currently.

That's not to say that the specification cannot be fixed, or that a fully independent implementation cannot be written. It's just not happened yet.

[bernhardreiter]

@dwd thanks for your note. So if there were an implementation with a license that is not freedom protecting (like Xorg Style or Apache-2.0) then swift and other clients could use it. Is there such an implementation? Otherwise would it mean that there is no spec and no-reference implementation that can be generally used? (If this would be the case then this would not meet the definition of an Open Standard by FSFE https://fsfe.org/activities/os/def.en.html see points 3. and 5.) :(

[dwd]

The problem isn't whether such an implementation exists, it's whether one can be created without reference to anything but openly published specifications. In that, I disagree with the FSFE's definition, which appears to mandate the existence of one or more implementations. I'd suggest instead that you look at the UK Government's principles, which are linked from the FSFE's:

https://www.gov.uk/government/publications/open-standards-principles/open-standards-principles#Defining-open-standards

Currently, OMEMO fails the second and third points of the selection criteria, and arguably all the points other than the fourth (RF licensing) of the "must also have" bit.

That's before one considers other aspects of OMEMO, like whether its design is actually as secure as it ought to be, and so on.

Of course, I'm deliberately taking a pretty strict line here, but the XMPP Standards Foundation has been known to persuade NATO to publish documents before accepting specifications, so the fact OMEMO exists as a XEP at all is evidence people have been pretty relaxed with this one.

[bernhardreiter]

@dwd, the question to me is if the OMEMO XEP-0384 is an open standard or not. If there is a) a spec that allows implementation or b) an implementation that everyone can use (like licensed without freedom protection), it would be an open standard. Your statement seems to indicate that XEP-0384 is not an open standard. But if an implementation under Apache 2 would exist then it would be an open standard (at least to me and FSFE).

[dwd]

But not to me or the XSF, because (b) is irrelevant (or rather, its only relevance would be to prove (a)).

At the moment, the specification simply isn't clear enough to implement from, and makes several assumptions about the use of libsignal. Every extant implementation uses libsignal, and every one has been worked on with detailed explanations from the original authors.

Moreover, all this presupposes that the design of OMEMO is actually making the right choices. I don't think it does, but given that previous feedback from outside the core group has been ignored (including mine), there seems little point in trying to address these.

As a result, I'll just wait patiently for MLS, which is an IETF work in progress and not only provides performance improvements over OMEMO, but will certainly qualify as an open standard.

[Kev]

Dave's mostly saving me the effort of replying here (thanks), I agree with what he says. At this point, given OMEMO's lack of progress, and MLS on the horizon, I'm not sure that even a ready-to-go PR submission with no side effects would be accepted into Swift.

[bernhardreiter]

@Kev @dwd thanks for your responses. Now I understand why this issue is closed. (Because you believe OMEMO not to be an open standard and not promising enough.)

For the record I'm assuming that MLS refers to "Messaging Layer Security" as being discussed here:

• https://messaginglayersecurity.rocks/
• https://datatracker.ietf.org/wg/mls/about/

[bernhardreiter]

Gathered some more info: one person who studied the xep-0384 said that it covers 90% what is needed for an implementation. So the rest could be understood by studying the reference implementations like https://github.com/tgalal/python-axolotl and https://github.com/tgalal/python-axolotl-curve25519. If you implement a new library by doing so, you'll get one that is no derivative of the original library, thus you can place it under and license you want, e.g. Apache-2.0.

The main reason for implementing OMEMO is that I see more and more people using it and thus it becomes a critical feature for a client. (And MLS seems to be years away, so waiting for it is no solution.) Implementing OMEMO is important to more use Swift-im's potential as XMPP client, just because many other clients implement it.

[bernhardreiter]

If you implement a new library by doing so, you'll get one that is no derivative of the original library, thus you can place it under and license you want, e.g. Apache-2.0.

This is confirmed by a moxie in this public discussion 2016 on ycombinator. He writes:

We haven't patented any of the concepts here, and we've done a lot to explain and popularize them. We're happy for people to use these concepts to build their own implementations

[bernhardreiter]

After more research with experts from the FSFE, it is more understandable to me that OMEMO is not considered as an open standard. It is widely held that there are ideas/concepts as opposed to an explicit expression of them, which would be code. So when looking at code you can learn the concepts. And if you implement concepts into your own implementation, there is no copyright involved, because there is no derived work. However some jurisdictions and courts have taken access to source and and similarity of code as a strong indicators of copyright violations. So if you want to profit from Free Software code under GNU GPL for your own independent implementation, the way to avoid legal insecurities is to do a clean-room approach, where one team reads the code and writes a concept and another team then only uses the concept documentation to do a "clean" implementation. If this procedure is documented, you can present it to courts.

So if the OMEMO standard is not enough for implementation and some people need to look in the source code of whisper systems, there is a real chance that whisper system may claim copyright violation, here is a report about a court case:
https://news.softpedia.com/news/wire-drops-lawsuit-alleging-extortion-from-signal-co-founder-503850.shtml also see the blog entry from wire about this https://medium.com/@wireapp/axolotl-and-proteus-788519b186a7 (as linked from the softpedia article).

[licaon-kter]

@bernhardreiter what revision of XEP-0384 is this ^^^ about?

[bernhardreiter]

@licaon-kter the main statement by @dwd is #37 (comment) and then the following comment from @Kev from October 2019, so they will have referred to v0.3.0 of https://xmpp.org/extensions/xep-0384.html#appendix-revs from July 2018.

Thanks for the hint that there is progress with XEP-0384 in March 2020 (v0.4.0 and v0.5.0).
@Kev and @dwd do you already have an opinion on the new progress of OMEMO?

Some possible drawbacks (that may still exist):

• XEP-0384 v0.5.0 is still "experimental", which means that is not suited in a production release according to https://xmpp.org/extensions/xep-0001.html#states-Experimental
• Is it possible to do a fully interoperable implementation just from the XEP-0384 and it referenced documents? (A clean room implementation.) A hint that this is the case would be an existing library that is licensed as Free Software under Xorg-style, Apache-2.0 or GNU LGPL v>=3.

[wiktor-k]

Hi @bernhardreiter,

You may see the revised comment from Dave on standards mailing list. A quote:

So, first off, I was wrong. The summary is that the Signal Protocol (and
the IV values, in particular) is most likely not to be encumbered. While
it's not 100% clear, the balance of evidence is that a non-GPL
implementation that is fully compatible could be written.

As for the drawbacks:

XEP-0384 v0.5.0 is still "experimental", which means that is not suited in a production release according to https://xmpp.org/extensions/xep-0001.html#states-Experimental

v0.5.0 (aka. omemo:1) was a collaborative effort of bunch of people that actually implemented the existing omemo v0.3.0 (aka siacs omemo). So this is definitely getting implemented as it fixes several shortcomings of current solution. And don't worry about "experimental" - just like OpenPGP 4880 bis is in draft shape but widely implemented a XEP may be "experimental" but being heavily used in the wild.

Is it possible to do a fully interoperable implementation just from the XEP-0384 and it referenced documents? (A clean room implementation.) A hint that this is the case would be an existing library that is licensed as Free Software under Xorg-style, Apache-2.0 or GNU LGPL v>=3.

I hope the quote from Dave above answers this question.

I understand that this may still leave OMEMO out of scope for Swift. Given that isode is targeted at military / governments end-to-end encryption may actually be something that's actually discouraged. Just recently I had a talk about how OMEMO "compromises message availability so not useful for business use".

[bernhardreiter]

@wiktor-k thanks for the update.

I understand that this may still leave OMEMO out of scope for Swift. Given that isode is targeted at military / governments end-to-end encryption may actually be something that's actually discouraged.

In my understanding it is the other way round: settings with high or very high security needs actually need better end-to-end encryption. A necessary availability fallback or document trace can be organised otherwise.

BTW: could https://gitlab.matrix.org/matrix-org/olm be used to implement OMEMO for swift-im? It would have the right license.

[wiktor-k]

In my understanding it is the other way round: settings with high or very high security needs actually need better end-to-end encryption. A necessary availability fallback or document trace can be organised otherwise.

That is to be decided by the Swift team I just wanted to highlight that there may be non-technical issues as to whether OMEMO is included or not. (Even if libsignal is GPL it could be offered as a plugin etc...)

BTW: could https://gitlab.matrix.org/matrix-org/olm be used to implement OMEMO for swift-im? It would have the right license.

This is unlikely because olm has a different set of constants and IVs from OMEMO. OMEMO didn't specify any change so using olm as-is would introduce incompatibility.