[Standards] OMEMO and Olm
matthew at matrix.org
Sat May 27 21:35:39 UTC 2017
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.
> On 27 May 2017, at 22:02, Sam Whited <sam at samwhited.com> wrote:
>> On Sat, May 27, 2017 at 3:41 PM, Remko Tronçon <remko at 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?
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: Standards-unsubscribe at xmpp.org
More information about the Standards