Cryptographic Issues in Matrix's Rust Library Vodozemac(soatok.blog)
15 pointsby u1hcw9nx9 hours ago3 comments
  • amluto6 hours ago
    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.

    • u1hcw9nx2 hours ago
      ?? It's explained just above the sentences you quote. And there is example just after the quote.
      • amluto2 hours ago
        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.

  • throawayonthe6 hours ago
    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

  • snvzz7 hours ago
    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.