Why I Don't Trust Matrix Developers to Produce a Secure Protocol

matrix.md

Update (2024-05-17)

Oh hey, this rant of mine is making the rounds.

After I wrote this, one of the Matrix leads commented on it, which prompted me to look at their code. I have since found, uh, 4 3 different cryptographic issues in Matrix's Olm and Megolm code.

Expect a blog post on Dhole Moments at some point in August.

One of them is extremely bad, and will put a lot of burden on Matrix users to mitigate effectively. False alarm: I was mistaken about this one. I'll include it in the write-up, though.

Original Gist Below

Ever since I wrote It's Time For Furries to Stop Using Telegram, I've had a few folks ask me about my opinion on Matrix.

(I've also had a few people evangelize Matrix in my mentions. That's annoying.)

My stance on Matrix has been the same for years: I don't trust the Matrix developers to produce a secure protocol, and until they abandon Olm / Megolm in favor of something like MLS, I'm adamant about refusing to trust their team's designs.

To understand why I feel so strongly about this, you need to understand that practically exploitable vulnerabilities were found in Matrix in 2022.

It isn't enough that there were vulnerabilities found to be alarming. Vulnerabilities happen. You aren't writing software if you don't occasionally fuck up.

The problem is the nature of these vulnerabilities. They're fucking clown-shoes. From the Q&A section of the disclosure:

a. Simple confidentiality break: The root cause of this attack is the fact that room management messages are not authenticated, which is a design flaw in the protocol itself, as no mechanism was specified for authentication of such messages.

Let me translate this for you: It apparently didn't occur to the developers who created Olm and Megolm to authenticate the messages that manage who has access to encrypted groups.

b. Attack against out-of-band verification: This attack exploits an insecure implementation choice enabled by a design flaw in the specification as there is no domain separation enforced there.

(Italic text is my emphasis.)

Not using domain separation was inexcusable in 2009, when Nate Lawson was angry about people continuing to write APIs vulnerable to length-extension attacks.

The Olm spec was written six years later in 2015.

A common pattern with the Matrix disclosure is wanting to ask, "Who was the cryptography adult in the room when this was written?" followed by the chirping of crickets.

d. Trusted impersonation: This is an implementation error as no check is performed to check whether Olm is used for encryption or not.

e. Impersonation to confidentiality break: This is an implementation error as no check is performed to check whether Olm is used for encryption or not.

This is a stupid bug to have. Maybe we can forgive these two.

f. IND-CCA break: This theoretical attack exploits a protocol design flaw.

The protocol design flaw, for the record, was using AES-CTR to encrypt information, then HMAC to authenticate the ciphertext, but not including the IV in the HMAC calculation.

This does not meet the bar for end-to-end encryption.

If these vulnerabilities were found from an earlier draft, then corrected by the team, I wouldn't mind so much. Iterative design is a thing in software development.

But if you want me to trust the protocol designs of people who felt qualified to design cryptography in 2015 when they didn't use domain separation, or completely forgot to authenticate their IV-- and didn't realize how badly they fucked up until Martin Albrecht, et al. pointed it out to them-- you're in for some disappointment.

Why is Matrix's design inadequate to meet the lowest bar?

Let's set aside the Cryptographic Doom Principle (which failing to authenticate the room management messages is a pretty glaring example of).

There are three things you have to test for in order to meet the lowest bar for a secure encrypted protocol design:

1. Encrypt a message. Then flip every single bit in the ciphertext, one at a time, including any unencrypted headers. Your protocol should reject every altered ciphertext with one bitflip, and the time it takes for this rejection to happen should not be dependent on any secret numbers.
2. Take some component of your system that gets hashed. Doesn't matter how it's hashed! Feed it into any other part of your system that uses hash functions. It should be rejected. You can try this with everything that hashes data or make it a rule to ALWAYS domain-separate your hashes.
   • Bonus round: If you're feeding a multi-part message into a hash function, you need to take care to avoid canonicalization issues.
3. When performing any kind of Diffie-Hellman key exchange, test against someone setting their public key to zero. Or to the prime of the field. Or to a low-order point if you're in a non-prime field (i.e. Montgomery curves). Matrix gets a point for this one, as far as I know.

To be clear

I do not believe there are any backdoors, nor am I aware of any specific unpatched vulnerabilities, in Matrix today EDIT: Spoke too soon! See the update at the top.

However, as a cryptography professional, I personally do not trust Matrix. I do not trust it because the people developing Matrix have not demonstrated the competence necessary to perform the task they believe they are doing.

Most people are not capable of meeting this high bar. Do not take it as a personal attack. But please abandon Olm and Megolm and work with the cryptography community to build something actually secure. MLS is a good start.

oh my god shut up

OMEMO is optional, meaning it's entirely possible to inadvertently send unencrypted something that you meant to be sent encrypted.

this kills the point of E2EE.

moreover I really do not give a single ounce of a shit about XMPP. see my first line above.

I agree that having OMEMO not be default is a pitfall of XMPP's e2e encryption, but the diversity of servers that exist on XMPP exist like the diverse keys for each individual user in an e2e encrypted chat. I can argue that diversity in TLS endpoints between servers and clients can provide the same benefits that e2e encryption does with global authentication via x509.

@saori-yuko You should learn what boundaries are. When someone says to stop, that does not mean continue fucking commenting.

But, my gods, what a dumb comment. I feel compelled to respond to it.

I agree that having OMEMO not be default is a pitfall of XMPP's e2e encryption,

The reason why I recommended Signal is simple: It's always encrypted. There isn't even a goddamn plaintext option. Signal's servers only see ciphertext.

Earlier you had claimed:

If you look at signals back end code there is 0 transport encryption within the hosting provider that they're using (this could also be the case with matrix's k8 clusters). All the endpoints behind the api gateway are plain http by avoiding this all the network requests are an extremely low hanging fruit.

This contradicts what I've been told in the past, that Signal uses the Noise Protocol instead of TLS to minimize complexity. But it wouldn't matter much even if it was true: they aren't shuffling plaintext around. They don't have plaintext to shuffle around!

OMEMO is a fucking clownshoes suggestion if it isn't a) deployed everywhere XMPP is, b) on by default, and c) unable to be disabled by careless users.

So take anything critical I said about Matrix, and multiply it by a large fucking number because XMPP is plaintext. End of story.

but the diversity of servers that exist on XMPP exist like the diverse keys for each individual user in an e2e encrypted chat.

Oh yes, even more unaudited code floating around is a good thing now.

What exactly do you think cryptography engineering is? The wild west?

Do you even have the vaguest idea how much of these "diverse" cryptography implementations I find vulnerabilities in without actually bothering to clone their Git repo, let alone building anything?

It doesn't matter if you have decentralized data storage if you're shoving plaintext to the server. This is the same idiocy that Threema and other designs use. "Well we're hosted in Switzerland!" as if that matters to cryptography one bit.

I can argue that diversity in TLS endpoints between servers and clients can provide the same benefits that e2e encryption does with global authentication via x509.

This is a weirdly worded sentence. It sounds like you're in favor of X.509, which brings all the fun of ASN.1 into a protocol that only needs one cryptography primitive for each use case.

Just, please, shut the fuck up.

It's interesting to hear someone who thinks e2e encryption can entirely replace transport encryption. Maybe we should switch back to SHTTP instead of HTTPS?

It's interesting to hear someone who thinks e2e encryption can entirely replace transport encryption.

That is not, at all, what I said.