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.
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.
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.
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:
- 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.
- 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.
- 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.
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.
hey - huge thanks for taking a look and following the SDP. would be super interested to know what you think of vodozemac, which is the Rust implementation we've switched to. (and yes, no desire for a message board debate here either)