[Standards] OMEMO Key Agreement

Chris Ballinger chrisballinger at gmail.com
Wed May 31 21:24:44 UTC 2017


It seems like the question is who will be responsible for doing the key
conversions between Curve25519 and Ed25519, the existing OMEMO
implementors, or the unknown future implementors who require permissive
licensing. I agree that it solves the license issue by having the existing
libsignal users convert their keys, but it will mean all existing
published/printed fingerprints are now visually invalid. It's a minor issue
but it could cause some confusion.

Agreeing upon a solution where the new permissive-only implementors can do
the key conversion on their end (without IP issues) means that no existing
implementations need to spend any engineering effort reworking/re-auditing
their crypto code.

On Wed, May 31, 2017 at 1:58 PM, Dave Cridland <dave at cridland.net> 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. It's no better, or more useful, than Ed25519 - and that's
> already in use in OpenSSH, and so on. TLS and DNSSEC support will not
> be based on XEdDSA; there would be absolutely no advantage to doing so
> - it'll be Ed25519.
>
> To Signal, this doesn't matter - they have good (really good)
> cryptographers and can maintain their implementation, and they've a
> need for the key compatibility that XEdDSA provides.
>
> So three or four years from now, we'll have Ed25519 everywhere, and -
> if you spend your money - two implementations of XEdDSA. FWIW, it's
> almost exactly ten years to the day that XEP-0118 was last updated,
> also using some niche crypto (anyone else remember eSessions and
> SIGMA?), and that, too, was implemented, and worked, and had
> deployment. And sunk without trace with only a single implementation.
>
> If we could ignore the future, this argument would not matter. If we
> could ignore the existing deployment, we could simply switch. But
> Remko has worked amazingly hard - and with a lot of patience in the
> face of ever-increasing hostility - and produced a proposal that
> doesn't abandon the deployed base by breaking older keys outright.
> Note that every implementation must surely change anyway if Andy's ODR
> PR goes in - so now is a good time to adjust other things in the
> protocol.
>
> Remko's proposal is, on the face of it, a workable plan to migrate
> from a niche bit of crypto that only one developer cares about enough
> to implement (or two, if you spend your money), to crypto primitives
> that are soon to be found in any reasonable crypto library.
>
> Dave.
> _______________________________________________
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: Standards-unsubscribe at xmpp.org
> _______________________________________________
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20170531/d6ecdd29/attachment-0001.html>


More information about the Standards mailing list