2/18/2026 at 11:05:50 AM
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.
by amluto
2/18/2026 at 2:53:36 PM
?? It's explained just above the sentences you quote. And there is example just after the quote.by u1hcw9nx
2/18/2026 at 3:18:36 PM
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.
by amluto
2/18/2026 at 5:05:07 PM
> 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...
by some_furry
2/18/2026 at 10:07:39 PM
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.
by amluto
2/18/2026 at 11:28:31 PM
https://soatok.blog/2026/02/17/cryptographic-issues-in-matri...by some_furry