4 ms·
> 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 wha
by some_furry 8mo ago
> 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-matrixs-rust-library-vodozemac/#:~:text=The%20first%20vulnerability,to%20other%20users. https://soatok.blog/2026/02/17/cryptographic-issues-in-matri...
- amluto 8mo agoYeah, 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.
- some_furry 8mo agohttps://soatok.blog/2026/02/17/cryptographic-issues-in-matrixs-rust-library-vodozemac/#vuln-1-attacker https://soatok.blog/2026/02/17/cryptographic-issues-in-matri...