https://soatok.blog/2026/02/17/cryptographic-issues-in-matrixs-rust-library-vodozemac/
-
I want to include this excerpt from the Matrix response:
Your PoC correctly demonstrates that the Olm 3DH implementation in vodozemac does not currently perform the all-zero DH output check. As we're sure you're aware, the check for contributory behaviour in X25519 is a contentious topic among cryptographers, with some calling for it, but others like RFC 7748[1] calling it optional or even arguing against it (e.g. Trevor Perrin[2]). We've previously considered adding it but ultimately avoided it due to the conclusion that there's no practical security impact on Matrix. In other places like SAS/ECIES we explicitly reject non-contributory outputs because those handshakes can be used in unauthenticated contexts where an all-zero DH output could directly collapse channel security.
The [2] points to https://moderncrypto.org/mail-archive/curves/2017/000896.html
Which is talking about the Diffie-Hellman primitive, not what protocols building atop ECDH should do.
Echoed for emphasis:
We've previously considered adding it but ultimately avoided it due to the conclusion that there's no practical security impact on Matrix.
Once again, they are insisting "We already knew about this risk but decided it's okay to not fix it or tell anyone about it".
Which is FUCKING BONKERS for a so-called secure messaging product!
-
Cryptographic Issues in Matrix’s Rust Library Vodozemac - Dhole Moments
If you're reading this after Matrix's blog post, make sure you read the addendum to this one. Two years ago, I glanced at Matrix's Olm library and immediately found several side-channel vulnerabilities. After dragging their feet for 90 days, they ended up not bothering to fix any of it. The Matrix.org security team also failed…
Dhole Moments (soatok.blog)
@soatok Do you know if this is exploitable? I wasn't clear on whether you traced it that far.
-
Cryptographic Issues in Matrix’s Rust Library Vodozemac - Dhole Moments
If you're reading this after Matrix's blog post, make sure you read the addendum to this one. Two years ago, I glanced at Matrix's Olm library and immediately found several side-channel vulnerabilities. After dragging their feet for 90 days, they ended up not bothering to fix any of it. The Matrix.org security team also failed…
Dhole Moments (soatok.blog)
@soatok One of the worst parts of matrix's popularity is how they stained the reputation of E2EE: People _expect_ E2EE to be inherently buggy and user unfriendly, so they tend to delay or avoid trying alternatives that are E2EE.
-
@soatok Do you know if this is exploitable? I wasn't clear on whether you traced it that far.
@varx Setting your own key to all zeroes sure sounds exploitable by a participant to me (and in a group chat it would seem to make a third party actor's work given access only to ciphertext much easier); and truncating a HMAC sounds like something a malicious party along the network data path could do.
So I would put both of those in the category of "plausibly exploitable" at least.
-
R relay@relay.mycrowd.ca shared this topicR relay@relay.infosec.exchange shared this topic
-
@varx Setting your own key to all zeroes sure sounds exploitable by a participant to me (and in a group chat it would seem to make a third party actor's work given access only to ciphertext much easier); and truncating a HMAC sounds like something a malicious party along the network data path could do.
So I would put both of those in the category of "plausibly exploitable" at least.
-
-
@soatok @kitkat @mkj @varx okay, hold on. so basically you're saying, "if the CSPRNG were to return all zeros, due to a defect or backdoor, the resulting shared secret will also be all zeros"?
but... let's say the vuln didn't exist, and the CSPRNG returned all 0xFFs instead.
then the attacker effectively knows the secret key of one of the participants. and so they can derive the same shared secret as the participant.
maybe I'm missing something, but I don't see how this is "Severity: High" -
@soatok @kitkat @mkj @varx okay, hold on. so basically you're saying, "if the CSPRNG were to return all zeros, due to a defect or backdoor, the resulting shared secret will also be all zeros"?
but... let's say the vuln didn't exist, and the CSPRNG returned all 0xFFs instead.
then the attacker effectively knows the secret key of one of the participants. and so they can derive the same shared secret as the participant.
maybe I'm missing something, but I don't see how this is "Severity: High"So, you're missing a couple of things:
- This failure can happen due to software/hardware bugs, and the all-zero shared secrets should be rejected by the protocol.
- This affects the privacy of group chats, not just 1:1 chats.
The severity is high because it leads to a total loss of confidentiality and integrity.
I didn't say likelihood was high or difficulty was low. That would have been critical
-
So, you're missing a couple of things:
- This failure can happen due to software/hardware bugs, and the all-zero shared secrets should be rejected by the protocol.
- This affects the privacy of group chats, not just 1:1 chats.
The severity is high because it leads to a total loss of confidentiality and integrity.
I didn't say likelihood was high or difficulty was low. That would have been critical
-
@mei @kitkat @varx @mkj That really depends on the source of the failure.
A cosmic ray is likely to flip 1 bit, but if it's in code, it could change a pointer and read the secret key from uninitialized memory. That could be random garbage. Or it could land out in a zeroed out mmap() region (which would make 0xFF less likely than 0x00).
The devil's in the details, and the details are complex and nuanced.
Rejecting the all-zero shared secret is what protocols built at a higher level of abstraction than the raw DH primitive are concerned with.
A user can set it deliberately, if they want, and Matrix happily accepts it.
A user can have this happen accidentally, in extremely low probabilities, and Matrix still happily accepts it.
Regardless of which of the two categories is happening, the outcome is the same.
-
@mei @kitkat @varx @mkj That really depends on the source of the failure.
A cosmic ray is likely to flip 1 bit, but if it's in code, it could change a pointer and read the secret key from uninitialized memory. That could be random garbage. Or it could land out in a zeroed out mmap() region (which would make 0xFF less likely than 0x00).
The devil's in the details, and the details are complex and nuanced.
Rejecting the all-zero shared secret is what protocols built at a higher level of abstraction than the raw DH primitive are concerned with.
A user can set it deliberately, if they want, and Matrix happily accepts it.
A user can have this happen accidentally, in extremely low probabilities, and Matrix still happily accepts it.
Regardless of which of the two categories is happening, the outcome is the same.
@mei @kitkat @varx @mkj If you want to argue that "Your evangelized as better than Signal E2EE group chat's encryption key is now revealed to the server operator without any indication of an error occurring" isn't a high severity issue, I don't think there's a discussion to be had.
I will remind you that the title of the blog post specifies that these are Cryptographic issues.
-
@mei @kitkat @varx @mkj If you want to argue that "Your evangelized as better than Signal E2EE group chat's encryption key is now revealed to the server operator without any indication of an error occurring" isn't a high severity issue, I don't think there's a discussion to be had.
I will remind you that the title of the blog post specifies that these are Cryptographic issues.
@soatok@furry.engineer @kitkat@climatejustice.social @varx@cybersecurity.theater @mkj@social.mkj.earth i think you're reading into things too much. to be clear: I'm not arguing matrix is a good chat protocol. anyone who's ever used matrix will know that. just by using the thing it's possible to tell they're leaking metadata like a sieve.
rather, what I'm arguing, is that your scenario of hypothetical software or hardware bugs messing with randomness doesn't justify the flippant attitude your blog post presents.
and sure, guarding against faulty CSPRNG is probably worth it. but if the vulnerability is that they don't guard against faulty CSPRNGs, then the fix should surely include some kind of statistical healthcheck being run before generating keys, or something like that?
TL;DR: if I was running a bug bounty, I'd probably mark this as "informative" at most. as it stands, without an explicit discussion of the scenarios which would need to happen for this to be exploitable, your blog post feels straight up dishonest.
and again, I say this having directly relied on Signal being secure in the past.
-
@soatok@furry.engineer @kitkat@climatejustice.social @varx@cybersecurity.theater @mkj@social.mkj.earth i think you're reading into things too much. to be clear: I'm not arguing matrix is a good chat protocol. anyone who's ever used matrix will know that. just by using the thing it's possible to tell they're leaking metadata like a sieve.
rather, what I'm arguing, is that your scenario of hypothetical software or hardware bugs messing with randomness doesn't justify the flippant attitude your blog post presents.
and sure, guarding against faulty CSPRNG is probably worth it. but if the vulnerability is that they don't guard against faulty CSPRNGs, then the fix should surely include some kind of statistical healthcheck being run before generating keys, or something like that?
TL;DR: if I was running a bug bounty, I'd probably mark this as "informative" at most. as it stands, without an explicit discussion of the scenarios which would need to happen for this to be exploitable, your blog post feels straight up dishonest.
and again, I say this having directly relied on Signal being secure in the past.
and sure, guarding against faulty CSPRNG is probably worth it. but if the vulnerability is that they don’t guard against faulty CSPRNGs, then the fix should surely include some kind of statistical healthcheck being run before generating keys, or something like that?
No?
The issue isn't CSPRNGs in particular. I avoided talking about CSPRNGs in my blog post because they're a magnet for conspiracy theorists and crackposts lol
The thing that needs to happen is simply what the patch I provided does.
TL;DR: if I was running a bug bounty, I’d probably mark this as “informative” at most.
You're thinking about this as an "end-to-end application security" mindset, not a cryptography mindset.
I specifically said they are Cryptographic Issues, not Security Issues.
When building cryptographic systems, you assume attackers have certain capabilities without needing to figure out all the ways they can attain those. "I set my PK to 0, group admin can read the history" is an attack. QED
-
@soatok@furry.engineer @kitkat@climatejustice.social @varx@cybersecurity.theater @mkj@social.mkj.earth i think you're reading into things too much. to be clear: I'm not arguing matrix is a good chat protocol. anyone who's ever used matrix will know that. just by using the thing it's possible to tell they're leaking metadata like a sieve.
rather, what I'm arguing, is that your scenario of hypothetical software or hardware bugs messing with randomness doesn't justify the flippant attitude your blog post presents.
and sure, guarding against faulty CSPRNG is probably worth it. but if the vulnerability is that they don't guard against faulty CSPRNGs, then the fix should surely include some kind of statistical healthcheck being run before generating keys, or something like that?
TL;DR: if I was running a bug bounty, I'd probably mark this as "informative" at most. as it stands, without an explicit discussion of the scenarios which would need to happen for this to be exploitable, your blog post feels straight up dishonest.
and again, I say this having directly relied on Signal being secure in the past.
An alternative take would be "thanks for the patch that brings us closer to following the relevant specification and avoids known caveats in implementing it".
*Even if* they think it's not an issue in practice.
For a piece of software that advertises confidentality + integrity, demonstrable loss of either is at a minimum a fix-worthy bug.
-
and sure, guarding against faulty CSPRNG is probably worth it. but if the vulnerability is that they don’t guard against faulty CSPRNGs, then the fix should surely include some kind of statistical healthcheck being run before generating keys, or something like that?
No?
The issue isn't CSPRNGs in particular. I avoided talking about CSPRNGs in my blog post because they're a magnet for conspiracy theorists and crackposts lol
The thing that needs to happen is simply what the patch I provided does.
TL;DR: if I was running a bug bounty, I’d probably mark this as “informative” at most.
You're thinking about this as an "end-to-end application security" mindset, not a cryptography mindset.
I specifically said they are Cryptographic Issues, not Security Issues.
When building cryptographic systems, you assume attackers have certain capabilities without needing to figure out all the ways they can attain those. "I set my PK to 0, group admin can read the history" is an attack. QED
-
@mei Or try "if one chat participant is using an implementation which is buggy in a user-undetectable way, then anyone on *every* participant's network can read the history" on for size. That's more in line with how I read what @soatok wrote. (Soatok, please feel free to correct me if I'm wrong here!)
-
Echoed for emphasis:
We've previously considered adding it but ultimately avoided it due to the conclusion that there's no practical security impact on Matrix.
Once again, they are insisting "We already knew about this risk but decided it's okay to not fix it or tell anyone about it".
Which is FUCKING BONKERS for a so-called secure messaging product!
@soatok which clearly shows that even if they could do cryptography, they sure as hell can not do security. sadly, it's a rather common mix of incompetence and arrogance.
-
@soatok which clearly shows that even if they could do cryptography, they sure as hell can not do security. sadly, it's a rather common mix of incompetence and arrogance.
