<div dir="ltr">Unlike most of those things you've mentioned, SignalProtocol (the protocol and reference libraries)┬áhas been extensively studied, audited, and widely deployed to billions of mobile devices. Other than Signal itself (a few million users), it's in WhatsApp (1.2 billion users), Facebook Messenger (1.2 billion users), Allo (a few hundred users), and more. I'd guess that SignalProtocol probably has a pretty safe future with the backing of a few multibillion dollar corporations.<div><br></div><div>That said:</div><div><br></div><div>1. I'd love a permissively licensed clean room implementation because it would help adoption and, more selfishly, allow me to offer commercial licenses of our software.</div><div>2. OMEMO-NEXT would be great for supporting out of <body> experiences.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jun 21, 2017 at 3:03 PM, Dave Cridland <span dir="ltr"><<a href="mailto:dave@cridland.net" target="_blank">dave@cridland.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 21 June 2017 at 15:35, Tobias Markmann <<a href="mailto:tmarkmann@googlemail.com">tmarkmann@googlemail.com</a>> wrote:<br>
> Here my long overdue summary of recent OMEMO discussions. Feel free to point<br>
> out errors and what not.<br>
</span>The only thing I'd add is a little history. I might wax a little<br>
cynical in this.<br>
When I started working with XMPP (I wrote a quick and dirty XMPP<br>
client in 24 hours), end-to-end encryption already had at least three<br>
designs, and I think a fourth was well on the way.<br>
One was based on libotr, Ian Goldberg et al's original Off The Record<br>
Messaging. It was actually only specified very recently in XMPP,<br>
though implemented as early as 2004 I think. I think this reached<br>
roughly the same levels of implementation as OMEMO - that is,<br>
exclusively a single library, but wrapped into a number of popular<br>
client projects.<br>
This was the "newer" kid on the block, though, the original being<br>
CMS-based (RFC 3923). Think S/MIME for XMPP, and you're about right.<br>
And where there's S/MIME, there's sure to be PGP - and sure enough,<br>
XEP-0027 was around, and, as I recall, used by about five people who<br>
bought lots of tinned food in bulk (I'm kidding - maybe - Psi had an<br>
implementation and possibly other clients too, but I didn't see it<br>
used much). RFC 3923 was, as befits anything based on S/MIME, used by<br>
absolutely nobody at all. Both failed because they didn't really work<br>
well, and were ugly as sin, too.<br>
The new one on the horizon was ESessions. ESessions was driven by a<br>
single developer, and used some fairly exotic crypto to perform<br>
roughly the same as OTR or OMEMO, albeit using older cryptographic<br>
primitives. It had one implementation (Gajim). It was last updated a<br>
decade ago. ESessions largely failed because it used exotic crypto<br>
primitives. These never got an audit, as far as I'm aware, but the<br>
fact they even needed one is a problem. Note that from a technical<br>
standpoint, there's really nothing at all wrong with the crypto in<br>
ESessions as far as I know. Nobody suggested there was, either.<br>
Then a few years on, and Silent Circle did SCIMP, which I'll count<br>
here because although not standardized it was running on XMPP.<br>
Every single one of these is now long dead, though OTR limps on in a<br>
few clients. (Unless you count OMEMO as being an ultimate derivative<br>
of OTR and SCIMP via Signal, of course).<br>
There's now three that I know of (or suspect strongly exist):<br>
OMEMO - single library, wrapped in a handful of clients. Some of those<br>
clients are very well deployed (although this was also true of<br>
XEP-0027 with Psi, OTR with Gaim/Pidgin, and ESessions with Gajim).<br>
OX - Like XEP-0027 with the deployed base of RFC 3923.<br>
MIKEY-SAKKE - Now I *think* there are XMPP-based implementations of<br>
this around the "Secure Chorus" market, but I've not actually seen<br>
anything yet. It's a offline key escrow IBE system, designed for<br>
governments and enterprises (ie, not consumers). The UK actually<br>
mandates its use in some cases (mostly to talk to it). Take a moment<br>
to enjoy the hysterical web search results.<br>
So it seems that the XMPP community is great at end-to-end encryption<br>
- in as much as we produce an astounding number of proposals - but<br>
less good at making them actually work in the market.<br>
With OX dead in the water, that leaves MIKEY-SAKKE, for the enterprise<br>
and (UK) government, and OMEMO, for the consumer.<br>
It's mildly annoying to have two entirely incompatible crypto<br>
protocols, but in fairness they're two almost entirely incompatible<br>
I would like not to have to update this history of failed protocols in<br>
another few years, therefore I would like OMEMO to not fall into any<br>
of the failure cases of previous attempts. I'd like to see lots of<br>
fully independent interoperable implementations. I'd like to see use<br>
of well-established, widely used cryptographic primitives.<br>
<span class="HOEnZb"><font color="#888888"><br>
</font></span><div class="HOEnZb"><div class="h5">______________________________<wbr>_________________<br>
Standards mailing list<br>
Info: <a href="https://mail.jabber.org/mailman/listinfo/standards" rel="noreferrer" target="_blank">https://mail.jabber.org/<wbr>mailman/listinfo/standards</a><br>
Unsubscribe: <a href="mailto:Standards-unsubscribe@xmpp.org">Standards-unsubscribe@xmpp.org</a><br>