[Standards] OMEMO and Olm
dave at cridland.net
Thu May 25 12:56:34 UTC 2017
On 25 May 2017 at 13:12, Vanitas Vitae <vanitasvitae at riseup.net> wrote:
> Am 25.05.2017 um 13:57 schrieb Matthew Hodgson:
>> 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?)
> Thats the idea of Andys ODR spec; decoupling the xep from libsignal/olm
> to allow any library to be used.
>> 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).
> Thats great news :) Also this indicates that there is more interest in
> XEdDSA than just from within the "Signal-OMEMO"-community.
>> (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).
> Thanks for the clarification on this one.
> Am 25.05.2017 um 10:47 schrieb Dave Cridland:
>> But it looks rather strongly as if every extant implementation of
>> OMEMO is simply a wrapper around a single crypto implementation.
> Than what's the difference when the XEP is switched over to use Olm?
> What would that change aside from another single crypto implementation
> being used?
My understanding is that one can "knock up" and Olm implementation
from existing crypto libraries. Ed25519, for example, is in several
crypto libraries, in several languages, whereas XEdDSA is only found
in libsignal currently. Support for Ed25519 (and Curve25519) is, for
example, coming "real soon now" in OpenSSL:
https://github.com/openssl/openssl/pull/3503 - but there's no sign at
all of XEdDSA that I can find.
Proponents of XEdDSA (and libsignal) have repeatedly made the claim
that building an XEdDSA implementation is both safe and
My concern is that nobody has done so.
There might be perfectly sound reasons for this, such as everyone
working on this has a particular desire for GPL'd output. I'm not sure
that thrills me, but still.
More information about the Standards