This posting will be shorter than it should be: the topic of popular, objective appraisal of diverse E2EE protocols and libraries is one that *ought* to take several blogposts by esteemed software engineers AND* cryptographers, but I lack the adequately current breadth of expertise, plus I’ve only had two coffees so far this morning.
So I’ll try to share some context, and end on a soundbite.###
ContextBack in 2015-16 I was the [lead engineer for adding end-to-end encryption (E2EE) to Facebook Messenger](https://alecmuffett.com/article/15058 ); the VP of the Messenger division was [David Marcus](https://x.com/davidmarcus ). My understanding at the time was that David felt pressure for Messenger to match Telegram’s functionality because of [competitive interests](https://www.theverge.com/2015/11/30/9819460/whatsapp-telegram-link-block-copy-paste ). Also, WhatsApp (owned by Facebook/Meta, but internally competitive with Messenger) was [adding encryption-by-default](https://www.bbc.co.uk/news/technology-35969739 ), which would make Messenger look less capable and less attractive.
Therefore: David proposed to follow Telegram’s approach to add end-to-end encryption to Messenger, and his vision was to satisfy marketing needs by adding a “tickbox” E2EE special-mode just like Telegram, because encryption was not then deemed significantly important as a product feature other than as a marketing exercise.
But it didn’t quite work out that way.###
Security InfrastructureI worked in a different, diverse, pan-company team called *Security Infrastructure* which was in charge of doing “security stuff”, everything from [FISA compliance](https://medium.com/@alecmuffett/how-to-talk-about-prism-and-not-get-entirely-blown-off-if-youre-an-activist-e2a79d2cd2ad ) to [making Facebook HTTPS-only](https://www.adweek.com/performance-marketing/https-default/ ) to putting [Facebook onto the Dark Web](https://www.theguardian.com/technology/2014/oct/31/facebook-anonymous-tor-users-onion ), and after doing the latter my boss told me *“Alec, why don’t you go end-to-end encrypt Messenger? See if you can do it.”*
So I did.
I grabbed a couple of experienced engineers and started checking code into the Messenger codebase until some product managers reached out to ask *“what the fuck are you doing?”*… which was actually my desired result, because it meant that I was now talking to the right people. This turned into a conversation, which turned into a serendipitous meeting with David Marcus who wanted the *Telegram competitiveness issue* to be addressed. And — fresh off the back of my success with putting Facebook onto Tor — I was tapped to be the engineering team lead and work with Tony, a Messenger-appointed Product manager, to deliver this. After a slightly wobbly start, Tony & I became a strong team, designing a solution based around *delivering a credible product*.
The thing is: Marcus also wanted us to *roll our own cryptography* on the grounds that we would (paraphrase) *“Get To Market Sooner That Way”* — but after more than 20 years of saying “don’t roll your own cryptography” to the general public, along with the popular adoption of ratcheting, Signal Protocol, and WhatsApp’s choice of the same, there was no way I was going to have my name attached to homebrew cryptography a-la Telegram, and I didn’t care if I had to fight a company VP to prevent that.
So we didn’t roll our own cryptography — we talked to the WhatsApp team, we embraced precisely the same code and library which WhatsApp already had, we got people in from Signal to consult. I spent a lot of time and late-night conference calls protecting my peers from senior management who were certain that we were wasting our time with “unnecessary complexity” when we could just throw OpenSSL and some key exchange code at the problem, because encryption was a [simple matter of programming](https://en.wikipedia.org/wiki/Small_matter_of_programming ).
Eventually we [delivered the first cut of end-to-end encryption for Messenger](https://www.wired.com/story/messenger-secret-messages-end-to-end-encryption/ ), which has subsequently been [re-engineered to be “by default”](https://about.fb.com/news/2023/12/default-end-to-end-encryption-on-messenger/ ) more that [five years after a tectonic company-wide shift in direction towards E2EE was ordered by Mark Zuckerberg](https://twitter.com/AlecMuffett/status/1089483304187973632 ).###
So, What’s The Beef?My reason for sharing this context is that I was listening to the [Security Cryptography Whatever podcast](https://securitycryptographywhatever.com ) over the weekend, the [most recent episode covering the Telegram affair, the Durov arrest, and so forth](https://securitycryptographywhatever.com/2024/09/06/telegram/ ). I do not agree with everything that was said — notably Tom’s assertion that (paraphrase) server-controlled group membership is innately a vulnerability, whereas I see it as a threat-model, TCB, and implementation issue; and Deirdre’s falling into the [Conway’s Law fallacy/trap](https://en.wikipedia.org/wiki/Conway%27s_law ) that somehow *federated software* will positively address European Regulation as-if obtaining granular control of privacy on a per-nation level was somehow the goal of European regulation in the first place (hint: it’s not.)
But the big takeaway for me was that… at some point Signal protocol is going, like OTR, to become too cumbersome for modern usage, it will start to fade, it will turn into the next libssl, and when that happens we will once-again be looking for fresh self-rolled software in the way that Signal’s own code at one point was a self-rolled effort.
If you’ve read this far, thank you, and I’ll try to summarise my feelings in an overly long soundbite:
> At some point Signal Protocol is going to need to be replaced, and I’m pretty sure that a committee won’t provide the thing which replaces it, because > [> if committee-designed messenger protocols worked for diverse use cases](https://alecmuffett.com/article/16086 )> then we’d all be excited to be extending some new functionality into > [> XMPP](https://twitter.com/AlecMuffett/status/1507355304807342088 )> . Stuff like Matrix similarly requires buying into an architecture and transport-layer lifestyle… ergo probably not that either. Group management will probably be the trigger for replacing Signal, but to get there will > [> require us to think more clearly about groups, boundaries of trust, and trusted computing bases](https://alecmuffett.com/alecm/e2e-primer/e2e-primer-print.html#boundaries-of-e2e-boundaries-of-ends )> . In any case: we will need to demand transparency but not be paranoid if/when big platforms decide to move away from “pure” Signal.
> Just so long as they don’t embrace MTProto, instead.
[*] …please, don’t listen to just *only* pure cryptographers, they are doom-mongers par excellence and you leave the encounter depressed and with a zeal to over-engineer things; you need some practical at-scale SWE experience in the mix, too
https://alecmuffett.com/article/110406
#endToEndEncryption #messenger #signal #telegram
