[Standards] OMEMO Update

Winfried Tilanus winfried at tilanus.com
Fri Feb 7 14:37:39 UTC 2020


On 2/4/20 6:24 PM, Winfried Tilanus wrote:

And then to reply to myself:
I incorrectly stated libsignal uses 'signal' in its protocol, that
should be 'whisper', what doesn't seem to be a trademark (but if anybody
knows otherwise...)

There is also some discussion going on if the constants are
copyrightable and if so if they can be uses as quotation. The kind of
case that would typically need a judge to decide on...

I guess it would be wise to try to get a written confirmation from Moxie
he won't sue us when we make our own implementation with these.

Winfried

> On 2/3/20 1:14 PM, Dave Cridland wrote:
> 
> Hi,
> 
> There are 3 parts with different IPR status.
> 1) The document describing the Whisper protocol this document is
> published as 'public domain'.
> 2) Libsignal, this is published as GPL
> 3) The trademark 'signal'.
> 
> Matthew told me at FOSDEM he wrote the E2E stuf of Matrix based on the
> public domain description of the Whisper protocol. He got written
> confirmation from Doxy that his implementation did not violate his IPR.
> 
> OMEMO uses libsignal, so it does not have the same status.
> 
> Within libsignal there are two parts that may hinder replication under a
> different license:
> - There are constants (that are needed for compatibility) in the code of
> libsignal, using the same constants in a rewrite under a different
> license can be seen as copying GPL'ed code to that different license.
> - There is the use of the word 'signal' as part of a handshake (and thus
> needed for compatibility). Rewriting the library and maintaining the
> 'signal' may be regarded as a violation of the trademark.
> 
> OMEMO uses both the constant and the trademark (because it uses
> libsignal). So I wouldn't say OMEMO is in the same safe waters as OLM.
> Two ways out: ask Doxy politely to re-license libsignal more permissive
> or to do a not line-by-line rewrite of libsignal without the constants
> and the trademarked word in the handshake. That would break
> compatibility with current implementations. I would rather invest in
> implementing MLS (given that the IPR issues there get sorted out).
> 
> Winfried
> 
> 
>> Hi all,
>>
>> So, first off, I was wrong. The summary is that the Signal Protocol (and
>> the IV values, in particular) is most likely not to be encumbered. While
>> it's not 100% clear, the balance of evidence is that a non-GPL
>> implementation that is fully compatible could be written.
>>
>> A number of people had conversations with Matthew of Matrix over the
>> past weekend, and while I'll paraphrase what I think he said to me, I'd
>> note that others have slightly different interpretations, so please
>> accept that some details may differ - the essentials are the same, though.
>>
>> 1) Wire: It's not clear why the legal spat started between Wire and OWS,
>> but it seems that the position of OWS was that it was a line-by-line
>> port, and therefore a derivative work in the meaning of copyright.
>>
>> 2) Olm: Matthew has, via email, an assertion that OWS would not attempt
>> any legal action if the license were followed. While Matrix's
>> implementation does indeed change the IVs (Initialization Vectors;
>> constants used to "prime" the encryption), this was done partly out of
>> an abundance of caution, and partly because OWS indicated that Signal
>> would never willingly federate, lessening the need for interoperability.
>> Olm has a proven specification - people have implemented Olm from the
>> specifications alone. I now believe, therefore, that using the same IVs
>> is probably safe legally.
>>
>> Therefore, I propose:
>>
>> a) OMEMO is fine as it is from a legal perspective.
>>
>> b) OMEMO (and OMEMO 2) should reference Olm as the specification, and
>> simply provide the new IVs. While I would be more comfortable using
>> Olm's IVs, this is - like Matrix - out of an abundance of caution.
>>
>> Dave.
>>
>> _______________________________________________
>> Standards mailing list
>> Info: https://mail.jabber.org/mailman/listinfo/standards
>> Unsubscribe: Standards-unsubscribe at xmpp.org
>> _______________________________________________
>>
> 
> 


-- 
privacy strategist & privacy architect
+31.6.23303960
https://www.tilanus.com/


More information about the Standards mailing list