Anyone know why the Diffie-Hellman issue supposedly matters in Matrix? The article complains extensively but devotes only a single sentence to answering the question.
> Does Non-Contributory Diffie-Hellman Matter?
> This is because the initial asynchronous ratchet handshake and KEMs require contributory material.
I imagine there are some details of Matrix needed to understand what this is trying to say.
I’m pretty sure that, in a non-Matrix setting, KEMs don’t really fundamentally contributory material. Sure, if you send me a bogus public key and I use KEM to generate a session key and email you a file encrypted against it, I’ve effectively sent plaintext, and if you send me an honest key I can choose a bogus ephemeral scalar and generate a fixed session key, but in either case the attacker knows the plaintext message anyway.
No, the article really doesn’t explain. It explains why the implementation can produce a fixed secret under malicious input, and that there’s an RFC saying “don’t implement it like this” but not what effect it has on the security of the system.
From a quick glance at the literature, failing to validate keys looks like it might break the Insider-CCA property, and maybe this affects some authenticated KEM constructions. And, just as a guess, maybe Matrix/Olm has a design such that this matters.
I agree with the author that the library should absolutely fix the bug or clearly document the specific reason it doesn’t and what is needed to retain security. But it looks like the explanation and the POC involve direct library calls and not the actual protocol except for that one sentence. And I’m curious what the protocol is doing.
> It explains why the implementation can produce a fixed secret under malicious input, and that there’s an RFC saying “don’t implement it like this” but not what effect it has on the security of the system.
Yeah, I get it. Their code quality is not great. They do a bad job of making it robust. There's a history here.
I'm still curious if this particular issue actually has a material effect on the protocol. I found a little bit more: "Consider also how this could affect a group chat." Okay, I considered it. I haven't the faintest clue how Matrix's group chat thing works [0], and I can totally imagine that, if a group's chat ciphertext is stored on an untrusted server and it's encrypted against a fixed key, then the server gets all the plaintext. But I also think that, if any participant in a group has permission to read all the messages, then they could also email the messages to the server operator, which makes it a little bit less interesting if they can maliciously force the key to be zero. (Maybe the key is also used for authentication of other parties -- I dunno. That's why I'm asking.)
[0] On the two occasions I've tried to use Matrix, I did not succeed in making a chat with more participants than just myself, so it seemed highly secure, and also completely useless.
> This observation leads to two possible interpretations (both bad):
- The Version 2 code is an unfinished experiment that should’ve been relegated to a development branch rather than dumped into the production version that real clients use today.
- The Version 2 code is intended to be used today, but Matrix is consistently incapable of designing protocols that resist even the laziest of active attackers.
i'm curious, could another interpretation be something like staggered rollout of v2? like, making sure clients already have the v2 code path for when other clients start disabling v1 idk
I git blamed it and if I read it correctly it seems like they even use version 1 as a default, because that's the actually spec compliant option: https://github.com/matrix-org/vodozemac/pull/287
Anyone know why the Diffie-Hellman issue supposedly matters in Matrix? The article complains extensively but devotes only a single sentence to answering the question.
> Does Non-Contributory Diffie-Hellman Matter?
> This is because the initial asynchronous ratchet handshake and KEMs require contributory material.
I imagine there are some details of Matrix needed to understand what this is trying to say.
I’m pretty sure that, in a non-Matrix setting, KEMs don’t really fundamentally contributory material. Sure, if you send me a bogus public key and I use KEM to generate a session key and email you a file encrypted against it, I’ve effectively sent plaintext, and if you send me an honest key I can choose a bogus ephemeral scalar and generate a fixed session key, but in either case the attacker knows the plaintext message anyway.
?? It's explained just above the sentences you quote. And there is example just after the quote.
No, the article really doesn’t explain. It explains why the implementation can produce a fixed secret under malicious input, and that there’s an RFC saying “don’t implement it like this” but not what effect it has on the security of the system.
From a quick glance at the literature, failing to validate keys looks like it might break the Insider-CCA property, and maybe this affects some authenticated KEM constructions. And, just as a guess, maybe Matrix/Olm has a design such that this matters.
I agree with the author that the library should absolutely fix the bug or clearly document the specific reason it doesn’t and what is needed to retain security. But it looks like the explanation and the POC involve direct library calls and not the actual protocol except for that one sentence. And I’m curious what the protocol is doing.
> It explains why the implementation can produce a fixed secret under malicious input, and that there’s an RFC saying “don’t implement it like this” but not what effect it has on the security of the system.
https://soatok.blog/2026/02/17/cryptographic-issues-in-matri...
Yeah, I get it. Their code quality is not great. They do a bad job of making it robust. There's a history here.
I'm still curious if this particular issue actually has a material effect on the protocol. I found a little bit more: "Consider also how this could affect a group chat." Okay, I considered it. I haven't the faintest clue how Matrix's group chat thing works [0], and I can totally imagine that, if a group's chat ciphertext is stored on an untrusted server and it's encrypted against a fixed key, then the server gets all the plaintext. But I also think that, if any participant in a group has permission to read all the messages, then they could also email the messages to the server operator, which makes it a little bit less interesting if they can maliciously force the key to be zero. (Maybe the key is also used for authentication of other parties -- I dunno. That's why I'm asking.)
[0] On the two occasions I've tried to use Matrix, I did not succeed in making a chat with more participants than just myself, so it seemed highly secure, and also completely useless.
https://soatok.blog/2026/02/17/cryptographic-issues-in-matri...
interesting blog post as always :)
> This observation leads to two possible interpretations (both bad):
- The Version 2 code is an unfinished experiment that should’ve been relegated to a development branch rather than dumped into the production version that real clients use today.
- The Version 2 code is intended to be used today, but Matrix is consistently incapable of designing protocols that resist even the laziest of active attackers.
i'm curious, could another interpretation be something like staggered rollout of v2? like, making sure clients already have the v2 code path for when other clients start disabling v1 idk
I git blamed it and if I read it correctly it seems like they even use version 1 as a default, because that's the actually spec compliant option: https://github.com/matrix-org/vodozemac/pull/287
Seeing the treatment reported vulnerabilities do get, I am increasingly leaning towards Full Disclosure.
Hell, the rational path might be to just sell vulnerabilities in the black market.