Thank you all for the thorough discussion in this thread. I don't usually post around here because things can get a little... heated. We're all on the same team here, and all want to see widespread, decentralized adoption of the best end-to-end crypto.
In an ideal world, an open specification for AxolotlV2/V3 would have been released years ago, leading to at least a few alternative wire-compatible libraries with permissive licenses by now. Because of the IP issues, there was a big delay getting something permissive out there... so we're stuck in this mess together. Olm was very new and experimental, and not really ready for production back when OMEMO was being formed, so the original specification being written for AxolotlV3 can't really be considered malicious tricks to force everyone to use GPL software. Because of the IP issues of GPLv3+iOS for SignalProtocol, we were very close to forking OMEMO to use Olm before there was even much discussion about it. Our choice to use SignalProtocol wasn't to help force adoption of a GPL'd encumbered standard.. it was dictated by a grant we wrote over a year earlier, and we had no option but to use libsignal-protocol-c once it was relicensed for GPL+ App Store. I don't have opposition to using Olm for any other reason than it will be costly to rewrite all of the existing clients. There isn't any funding for us to rewrite for Olm just to gain permissive license purity. Even if we started fundraising for that now, grants can lag up to a year, or get declined. I think that a permissively licensed alternative to using OWS's libraries would be best for long term adoption, so if there's a way we can make that happen involving the least amount of code changes, that would be ideal. On Sat, May 27, 2017 at 2:35 PM, Matthew Hodgson <matt...@matrix.org> wrote: > This is really interesting - I'm surprised that conversion between > Curve25519 and Ed25519 was that straightforward. > > In terms of whether you should use libolm or libsignal: libolm's DR > protocol (olm) is intended to be very close to libsignal's: to my knowledge > the only differences are the seed constants used, the whole XEdDSA v > separate-key thing, and probably some fairly minor bit packing differences > in terms of the payloads (particularly whether one-time-keys are signed at > the app layer or the protocol layer, iirc). Making them bit compatible (or > forking a dialect of Olm that was bit compatible with libsignal's DR) looks > at first glance like a relatively tractable amount of work, especially > relative to writing a whole new DR implementation. > > The main differences are: > * the licence (GPLv3+iOS-appstore-exception for libsignal, versus Apache > for libolm) > * the audit (libolm's audit is public, unlike libsignal's) > * the provenance (UK/EU rather than US, for those who care about US > crypto export legislation) > * the fact that Olm's authors are interested in decentralisation (whether > that's via XMPP or Matrix), and encourage Olm to be used as a generic DR > library by all and sundry. > * the (im)maturity - obviously OWS has a few year's head start on us, not > to mention inventing the tech :) > > To reiterate: we would have no problem at all in someone forking Olm and > bringing it to parity with libsignal's DR, and then using it as an > Apache-licensed DR for the greater glory of whichever protocol. > > Right now we have our hands full enough with getting Megolm history > sharing & key management working well in Matrix, and XEdDSA compatibility > is the least of our concerns. But it would be great to see someone try it, > and we could certainly help get it audited too (cf Daniel's mail earlier). > And if it worked out I see no reason why we wouldn't start using it too - > would be a good excuse to test bootstrapping crypto upgrades within Matrix. > > M > > -- > Matthew Hodgson > Matrix.org > > > On 27 May 2017, at 22:02, Sam Whited <s...@samwhited.com> wrote: > > > >> On Sat, May 27, 2017 at 3:41 PM, Remko Tronçon <re...@el-tramo.be> > wrote: > >> And you got all this just by looking at the XEdDSA spec? Maybe to you > this > >> is trivial, but I don't understand how parts of the pseudocode in the > spec map > >> to the code you wrote (e.g. the ScCMove bit is pure magic to me, I would > >> never have come up with that). I still consider this way out of the > comfort zone > >> of mere mortal developers like me. > > > > Oh pardon me, that was a poor choice of words, I didn't mean to > > suggest that it's not tricky (it took me several readings to > > understand what was going on, and I was very confused and had to ask > > Andy for advice several times). I wanted to show that if you already > > have a crypto library that implements ed25519, doing the key > > conversion is only a few extra lines of code and isn't an > > insurmountable barrier (though it does certainly help to know a bit > > about the underlying operations; eg. CMov is an operation that copies > > data if some condition is true, but without actually branching, which > > makes things a lot faster). If I can dig in and get a working > > implementation in a day or two, someone who really knows what they're > > doing could have done it much quicker without taking so much time to > > study the spec (this is the sense in which it's "trivial"). The > > important thing is that, I think (again, we'll see what the review > > looks like), this shows that if XEdDSA is used that new > > implementations can be created under whatever license without a huge > > amount of hassle; now we can try to make up our minds about which is a > > better alternative without worrying about licensing (I hope). > > > > Personally, I've gone from more or less in the middle to leaning > > towards Andy's line of thinking: implementing the key conversion is a > > minor pain compared to transitioning existing clients to the Olm based > > version of the spec. I see no technical benefits to either approach > > that sway me as much as the amount of work that I suspect it would be > > to move the two Pidgin plugins, Conversations, Gajim, the existing > > work on ChatSecure or ZOM (or whatever it's called now), Dino, and > > maybe others over to a new spec. I'd love to be proven wrong though; > > I'd much rather be be deciding based on purely technical arguments > > about which is faster/safer/etc. > > > > Maybe someone should try to port one of the complete implementations > > over and see how difficult it is? > > > > —Sam > > _______________________________________________ > > Standards mailing list > > Info: https://mail.jabber.org/mailman/listinfo/standards > > Unsubscribe: standards-unsubscr...@xmpp.org > > _______________________________________________ > > _______________________________________________ > Standards mailing list > Info: https://mail.jabber.org/mailman/listinfo/standards > Unsubscribe: standards-unsubscr...@xmpp.org > _______________________________________________ >
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
