[Standards] OMEMO and Olm

Matthew Hodgson matthew at matrix.org
Thu May 25 11:57:11 UTC 2017


On 5/25/17 12:31 PM, Vanitas Vitae wrote:
> Hi!
> 
> Am 25.05.2017 um 10:47 schrieb Dave Cridland:
>> Rightly or wrongly, there are other benefits of using Olm, such as 
>> interoperability with Matrix, the availability of existing low and 
>> high level libraries, etc.
> Correct me if I'm wrong, but there is still no java implementation,
> right?

There is http://matrix.org/git/olm/tree/android, which provides JNI 
wrappers around libolm for use in Java.  In general this is preferable 
(performancewise and auditwise) to a native Java implementation.

There's also someone in the community shifting the build from being 
android/gradle to generic Java, although this isn't exactly a lot of work.

In terms of the general question of libsignal-* versus Olm: it's worth 
noting that using precisely the same ratchet for both Matrix & XMPP 
doesn't necessarily buy much, given the payloads put over the ratchet 
will end up being inevitably different.  The main advantage of doing so 
would be to just benefit from the audit & ongoing maintenance work 
that's going into Olm, as well as the more liberal licensing.

But if OMEMO-using-libsignal has critical mass already, I completely get 
the concerns over disrupting the existing ecosystem over 'just' a 
licensing issue, and perhaps the work would be better spent writing an 
liberal-licensed ratchet which is absolutely 100% compatible with 
libsignal (including XEdDSA) etc.  This could be by extending/forking 
Olm to use XEdDSA, or if you're feeling completely masochistic, a whole 
new implementation.  Then folks on OMEMO-using-libsignal would be able 
to talk happily to folks on 
OMEMO-using-liberal-licensed-DR-implementation, and everyone's happy (i 
think?)

For the record, if someone did jump through the hoops to make Olm talk 
XEdDSA we'd probably consider using it on the Matrix side (both to avoid 
a fork, and to help pool crypto resources between XMPP & Matrix, and 
keep compatibility with folks who want to use GPL-licensed libsignal, etc).

(In other news, I saw Remko mention elsewhere that an advantage of Olm 
might be using Megolm-style semantics for XMPP.  I'd caution that Megolm 
is very much experimental still, and we're not sure all the design 
decisions are optimal.  More importantly, it's completely decoupled from 
Olm, despite the name, and could be layered on top of a 
libsignal-managed 1:1 channel just as much as an olm-managed one).

M


-- 
Matthew Hodgson
Matrix.org


More information about the Standards mailing list