Matrix disputes “confidentiality break” claims in crypto library

Matrix.org has rejected claims that critical vulnerabilities in its Rust-based cryptographic library, vodozemac, allow attackers to read private conversations.

While acknowledging a missing validation check in its Olm key exchange implementation, the Matrix security team says the reported issues do not translate into “practically exploitable vulnerabilities” in real-world Matrix deployments.

Matrix is an open-source, decentralized messaging protocol used by governments, enterprises, and public communities, with end-to-end encryption provided by Olm for one-to-one chats and Megolm for group conversations. Vodozemac is its modern Rust replacement for the older libolm library.

The controversy began with a February 17, 2026, blog post by independent security researcher Soatok, who disclosed several alleged cryptographic weaknesses in vodozemac. The issues were privately reported to Matrix on February 11, with public disclosure following less than a week later. Matrix published its response yesterday, disputing both the severity and exploitability of the findings.

All-zero Diffie-Hellman output at the center

The primary issue concerns the Olm 3DH handshake, which derives session keys from three X25519 Diffie-Hellman computations involving long-term identity keys and ephemeral pre-keys.

Soatok argues that vodozemac fails to reject all-zero shared secrets, also known as non-contributory outputs, allowing a participant to set their public key to zero and force predictable session keys. In his assessment, this could lead to a complete loss of confidentiality, including exposure of Megolm group session keys to the homeserver.

Matrix confirms that the library does not currently check whether Diffie-Hellman outputs are all zeros using the was_contributory() safeguard available in the underlying x25519-dalek library. However, it disputes the attack scenario.

According to the Matrix security team, identity keys and pre-keys used in the handshake are signed with each device’s long-term Ed25519 key and verified before session establishment. This authenticated key distribution model prevents a network attacker from injecting malicious low-order keys into the exchange.

Matrix argues that for the attack to succeed, an adversary would need to force both parties to derive identical, attacker-controlled outputs for all three Diffie-Hellman operations, something it says is not achievable under the current protocol design. The researcher counters that the attack involves a malicious participant setting their own public key to zero, rather than a man-in-the-middle substitution.

Despite the disagreement, Matrix says it will add an explicit all-zero output check in a future vodozemac release as a defense-in-depth measure.

Downgrade and other reported issues

The researcher’s post also raises concerns about:

• Downgrade attacks from Olm v2 to v1, where v1 uses truncated 64-bit message authentication codes (MACs). Matrix responds that Olm v2 is experimental, not yet standardized, or deployed, making downgrade scenarios theoretical.
• Truncated 64-bit MACs in Olm v1, which Matrix acknowledges as a legacy design trade-off, noting that similar tag lengths are used in other deployed messaging systems.
• Hard-coded message key limits that the researcher claims could result in undecipherable messages. Matrix says these constants are empirically chosen reliability parameters, not security flaws.
• Strict Ed25519 verification is disabled by default, described by Matrix as a compatibility trade-off aligned with RFC 8032.

One initially reported issue involving disabled MAC verification under a Rust fuzzing configuration was later retracted by the researcher.

Matrix maintains that there is no demonstrated method to decrypt conversations between honest clients under its threat model and says it has not observed exploitation in the wild.

Users are advised to keep Matrix servers and clients up to date and monitor upcoming vodozemac releases, which will include the additional Diffie-Hellman validation check.