[Standards] OMEMO Key Agreement

Florian Schmaus flo at geekplace.eu
Wed May 31 21:50:15 UTC 2017

On 31.05.2017 22:58, Dave Cridland wrote:
> On 31 May 2017 at 21:16, Chris Ballinger <chrisballinger at gmail.com> wrote:
>> This is all so ridiculous. If I arrange funding for a permissive XEdDSA
>> implementation and audit can we stop making personal attacks and move on
>> from this nonsense?
> When the next major OpenSSL release comes out - which many XMPP
> clients will want to be using to get TLS 1.3 - it'll almost certainly
> have everything required to build Remko's proposal. Meanwhile, you can
> build it now from libsodium, for example.
> But XEdDSA is an algorithm unique to Signal's needs. It honestly
> doesn't matter if it's good crypto or not - and I believe it's
> entirely sound - it won't see widespread adoption because it's such a
> niche.

Quite contrary I suspect that if we never switch XEP-0384 towards XEdDSA
the existing user base won't follow whatever the XEP says and will
continue to use XEdDSA for the foreseeable future (which I would call
widespread adoption of XEdDSA).

Nevertheless that Sam's Go submission is very likely a violation of
license terms if it gets merged as is, I, just like Daniel, think that
asking people to create a XEdDSA implementation under a license that
suits their needs is not to asking to much.

On the other hand, considering that OMEMO is major success and a big
step towards an open standard end-to-end encrypted alternative to the
existing proprietary messaging systems, I think it is unrealistic to
push a change that will render the currently used fingerprints invalid.

For the same reasons, and on a first look, I feel like Remko's Key
Agreement v2 suggestion just introduces unnecessary additional complexity.

- Florian

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 642 bytes
Desc: OpenPGP digital signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20170531/b0d6d44a/attachment.sig>

More information about the Standards mailing list