profile
viewpoint

swift/swift 172

Swift XMPP client and Swiften XMPP library

swift/stroke 4

Java XMPP library

swift/echobot 0

EchoBot

swift/swiftob 0

Scriptable XMPP Bot

swift/trelloxmpp 0

Bot to relay activity from Trello boards to XMPP MUC rooms

fork chat-x/swift

Swift XMPP client and Swiften XMPP library

http://swift.im/swift

fork in 20 days

startedswift/swift

started time in 23 days

startedswift/swift

started time in a month

startedswift/swift

started time in a month

startedswift/swift

started time in a month

startedswift/swift

started time in 2 months

issue openedswift/swift

[Feature] Add OMEMO v>0.5.0 (omemo:1) support for End-to-end crypto

Please consider omemo:1 for implementation to keep and grow swift-im's appeal to a wide range of users. Other pledges for this

  • https://github.com/swift/swift/issues/37#issuecomment-405041538
  • https://github.com/swift/swift/issues/37#issuecomment-544553239

The previous request for OMEMO #37 was closed because the 2018 OMEMO specifications were considered not good enough.

In 2020 new OMEMO specs were published and the estimation of @dwd is now that they can be independently implemented.

relevance

For XMPP to stay relevant it would need a good and usable end-to-end encryption, which is not burdened with X509 certificate processes. swift-im and its library can help a lot and offer a secure alternative to Matrix, as Matrix is gaining traction with high profile users because of the ease of its encryption.

E.g. German military considers Matrix

  • https://www.golem.de/news/messenger-bundeswehr-will-komplett-auf-matrix-chat-wechseln-2005-148407.html (sorry in German)

e.g. the French government uses Matrix as well

  • https://matrix.org/blog/2018/04/26/matrix-and-riot-confirmed-as-the-basis-for-frances-secure-instant-messenger-app

created time in 2 months

startedswift/swift

started time in 2 months

startedswift/swift

started time in 2 months

startedswift/swift

started time in 2 months

issue commentswift/swift

Add Omemo Encryption Support

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.

dreamflasher

comment created time in 2 months

issue commentswift/swift

Add Omemo Encryption Support

@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: setting with high or very high security needs actually need better end-to-end encryption. A necessary 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.

dreamflasher

comment created time in 2 months

startedswift/swift

started time in 2 months

issue commentswift/swift

Add Omemo Encryption Support

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

dreamflasher

comment created time in 2 months

issue commentswift/swift

Add Omemo Encryption Support

@licaon-kter the main statement by @dwd is https://github.com/swift/swift/issues/37#issuecomment-539509872 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.
dreamflasher

comment created time in 2 months

PR opened swift/swift

Swift 4.x

https://github.com/swift/swift/compare/master...swift-4.x#diff-b593b27e456b25560d0d8eafe7c399d8

+6 -6

0 comment

2 changed files

pr created time in 2 months

startedswift/swift

started time in 2 months

issue commentswift/swift

Add Omemo Encryption Support

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

dreamflasher

comment created time in 2 months

issue commentswift/swift

Add Omemo Encryption Support

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

dreamflasher

comment created time in 2 months

startedswift/swift

started time in 3 months

startedswift/swift

started time in 3 months

more