[Standards] OMEMO Key Agreement
dave at cridland.net
Wed May 31 20:58:19 UTC 2017
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
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.
More information about the Standards