[Standards] OMEMO and Olm

Andreas Straub andy at strb.org
Wed May 24 20:55:11 UTC 2017

Hey all,

it has been brought to my attention that my recent silence on this 
matter is being perceived as "unresponsiveness", so I guess I should 
clear up a few things.

I haven't commented on this issue in a while because I don't feel I have 
anything significant to add at this point. Most of the arguments have 
been made (by me and others) months ago, and nothing significant has 
changed. I generally try to refrain from repeating things others have 
already said, especially on mailing lists, and I guess I just wasn't 
aware that that's exactly what the XSF process required me to do in this 
case. Sorry about that. So let me try to sum up where we stand right now.

First, for a bit of additional background, I suppose I should clear up 
the misconception that (under my proposed changes) OMEMO would be 
"moving away from OLM". As far as I'm concerned, OMEMO wasn't ever 
actually on OLM. Due to the poor standardization of signal-protocol at 
the time, we changed the spec to using OLM, but this was never actually 
implemented. There were plans to switch over, but before anyone got 
around to putting in the (not insignificant amount of) work, the 
standardization issues with signal-protocol resolved themselves (in 
particular, the whole "any implementation would be a derivative of ours 
and hence bound by the GPL" thing isn't true anymore, as there is a 
complete spec that's placed in the public domain). So as far as we were 
aware at the time, the singular roadblock that prevented us from 
standardizing on signal-protocol back in the day was gone, and there was 
no longer a strong argument for proceeding with this changeover, which 
would've meant a lot of effort for existing implementations at basically 
no concrete benefit.

Hence, the main impetus driving me to work up a new revision was to 
*move the spec back in line with the real world*, not some kind of 
"political" move or anything of the sort as has been insinuated on this 
list. We've had an increasing number of developers interested in 
implementing OMEMO for different clients, and it's really dumb to have 
to tell everybody to ignore what the standard (that you yourself wrote) 

So what I care about is resolving this situation in a way that actually 
helps people. I want people to be able to implement this protocol 
without reading others' code or asking around which parts of a spec to 
ignore and which ones to follow. Staying in this limbo, as was suggested 
on this list at some point ("it's experimental, you can just stay on 
your private namespace for now") is in my opinion antithetical to the 
whole idea of even having a standard in the first place.

As far as I can tell, switching to OLM does not help anyone. I am not 
aware of any individual, organization, or company that is interested in 
implementing OMEMO but *can't* due to licensing issues. The original 
criticism of lacking specification is resolved. The spec is public 
domain, and it contains everything you need to roll your own library. 
But apparently, the goalposts have moved, and we now also require a 
permissively licensed implementation.

Yes, it's true that there's currently no such thing for XEdDSA, but is 
this actually a concrete problem for anyone? As far as I'm aware, this 
has always been a purely hypothetical debate. If I'm wrong here, please 
speak up! In any case, when it comes down to it, implementing this 
yourself really isn't that complex. You can re-use existing EdDSA code, 
all you need to do is write the key conversion code yourself, for which 
there is pseudo-code in the standard, which maps fairly directly to 
well-known mathematical primitives, for which you can also re-use 
existing code. The main novel idea in XEdDSA is resolving an ambiguity 
in the conversion by forcing a sign bit to 0, and that's about it. Your 
code doesn't have to be constant-time and if you do it wrong, the 
signature just won't verify. I agree that it's never ideal to have to do 
stuff like this yourself, but this also isn't quite as "playing with 
fire" as some folks are making it out to be. In any case, I really doubt 
that this is the one big thing that would hinder such hypothetical 
implementors from adopting OMEMO.

To make a long story short, I remain unconvinced that switching to OLM 
makes sense at this point. The way I see it, moving forward with that 
amounts to preventing some inconvenience for an entirely hypothetical 
set of implementors at the cost of screwing over an entire existing, 
working ecosystem.

It's easy to throw around things like "it's experimental, so we can mess 
with it however we like and client devs will just have to deal with it", 
especially if you have no skin in the game. But for the stakeholders who 
are actually working on and using the technology, stuff like this is a 
huge deal. OMEMO is a pretty successful and established protocol at this 
point, and to be honest I just don't see the major implementations 
switching over any time soon. Who's going to put in all that work? And 
what do we do until then?

All that said, maybe my assessment of the situation is totally off. If 
the wider community still wants to move forward with this, then I don't 
want to be the only one standing in the way. But in that case, somebody 
else should probably take over.


On 05/17/2017 05:59 PM, Dave Cridland wrote:
> Folks,
> My understanding of OMEMO was that we (the XSF) took on the work
> explicitly under the assumption that it was not to be based on the
> Signal protocol, which had IPR issues, but on Olm, which was
> explicitly designed, documented, *and* implemented to avoid such
> issues.
> You may recall (I certainly do) lengthy discussions about OWS's
> tendency to threaten legal action on alternate implementations of
> their protocol, particularly their stance that *any* implementation
> was bound by the GPL.
> As I understand things right now, in order to implement OMEMO one has
> to fork libsignal - no other path exists without playing with
> fundamental primitives.
> A lengthy discussion ensued on this list, involving both Matthew
> Hodgson and others who clearly know a lot more about Crypto than I do.
> None of their arguments were answered. Remko supplied a PR to match
> these. It seems to be being ignored, then rejected out of hand.
> Am I wrong, if so, where?
> Dave.
> _______________________________________________
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: Standards-unsubscribe at xmpp.org
> _______________________________________________

More information about the Standards mailing list