Repository navigation
Add Omemo Encryption Support #37
Description
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
Activity
Kev commentedon Jan 23, 2017
Thanks for the suggestion. It's something we're considering for the future, but is not currently on the roadmap.
Kev commentedon Apr 3, 2017
@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 commentedon Jun 12, 2017
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).
flawrist commentedon Jun 12, 2017
“Are we OMEMO yet?” website gives an overview of the status of implementation across XMPP clients.
tdemin commentedon Nov 14, 2017
@remko hasn't it? It has got its XEP number (XEP-0384) in December 2016.
dreamflasher commentedon Nov 14, 2017
@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 commentedon Jan 6, 2018
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 commentedon Jan 6, 2018
No news. Nothing has happened on the protocol to address the concerns mentioned before, so nothing has happened on the Swift side either.
dreamflasher commentedon Jan 6, 2018
That's quite incorrect. As previous comments pointed out everything is good on the Omemo side.
Kev commentedon Jan 6, 2018
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 commentedon Feb 27, 2018
@Kev but as I understand, you are generally willing to implement, once there is a sufficient standardisation, correct?
Cheers
Kev commentedon Feb 28, 2018
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).
flawrist commentedon Feb 28, 2018
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 commentedon Feb 28, 2018
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.
6 remaining items
dwd commentedon Oct 7, 2019
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 commentedon Oct 8, 2019
@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 commentedon Oct 8, 2019
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 commentedon Oct 8, 2019
@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 commentedon Oct 8, 2019
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 commentedon Oct 8, 2019
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 commentedon Oct 8, 2019
@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:
bernhardreiter commentedon Oct 21, 2019
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 commentedon Oct 22, 2019
This is confirmed by a moxie in this public discussion 2016 on ycombinator. He writes:
bernhardreiter commentedon Apr 30, 2020
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 commentedon Apr 30, 2020
@bernhardreiter what revision of XEP-0384 is this ^^^ about?
bernhardreiter commentedon May 4, 2020
@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):
wiktor-k commentedon May 4, 2020
Hi @bernhardreiter,
You may see the revised comment from Dave on standards mailing list. A quote:
As for the drawbacks:
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.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 commentedon May 4, 2020
@wiktor-k thanks for the update.
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 commentedon May 4, 2020
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...)
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.