3 ms·

> The point is that if your threat model cares about interception, you have to verify the identity of users out of band - same as Signal or WhatsApp or whatever

> The point is that if your threat model cares about interception, you have to verify the identity of users out of band - same as Signal or WhatsApp or whatever. I’ve read your blog posts and this comment, congratulations it seems to have satisfied most people. Howerver it is NOT the same as Signal. Signal servers cannot just add a device to a group chat. I would challenge you to get one reputable cryptographer to back what you’re claiming about these vulnerabilities and your proposed fixes. To me Matrix isn’t secure, the organizations responses to these disclosures has been poor and the “fixes” weak.

Arathorn 4y ago
You are completely misinterpreting my quote, which makes me question whether you are acting in good faith. Totally agreed that Signal servers cannot just add a device to a group chat. What I saying was: in any system, you have to verify users for security in general. Having verified users in Matrix, you then get a massive red warning if an unverified device is added to their accounts. Given we have cross-signing (i.e. users are heavily encouraged to verify their own devices when they log in), you can be sure that such unverified devices are malicious and take appropriate action. The obvious thing we could do is to go one step further (as we used to, until we backed it out in https://github.com/matrix-org/matrix-react-sdk/pull/3837 https://github.com/matrix-org/matrix-react-sdk/pull/3837) and stop messages from flowing until the unverified device has been dealt with. Even better would be to make group membership controlled by the clients, so the server can't add devices at all. And we're working on this, as part of shifting the implementations over to the audited matrix-rust-sdk-crypto implementation to avoid having to solve the problem in quadruplicate. > I would challenge you to get one reputable cryptographer to back what you’re claiming about these vulnerabilities and your proposed fixes. Hopefully someone will pop up here and confirm that I'm not talking shit :) Failing that, you'll have to wait for the next Least Authority audit - we have another independent public audit queued once this wave of work finishes to address the "To me Matrix isn't secure" polemicists. You can see the last one (on the crypto layer, rather than the group membership layer) at https://matrix.org/blog/2022/05/16/independent-public-audit-of-vodozemac-a-native-rust-reference-implementation-of-matrix-end-to-end-encryption https://matrix.org/blog/2022/05/16/independent-public-audit-... fwiw.
- cvwright 4y ago
  It’s encouraging to hear that you’re getting an audit of the new approach. Reading over the new design doc for authenticating membership events, and the Github comments, it feels like this is a case for some sort of model checking or automated theorem proving. Manually verifying that the new system does everything we want seems… tough.
  - tptacek 4y ago
    Here I'll point out that Matrix had audits commissioned prior to this research as well. Audits are a good thing, but one reason the previous audits didn't hit on this stuff is that the scope of the audit was sharply limited.
    - Arathorn 4y ago
      Totally agreed. We didn’t have the $ to do more than libolm at first, and then we did vodozemac in May. That one was the first of 4 planned audits, the rest of which go up the rest of the stack (respectively matrix-rust-sdk-crypto, matrix-rust-sdk, and then end-to-end across the whole stack). It is very frustrating we couldn’t do the rest of the stack sooner - and this hopefully explains why we are consolidating on matrix-rust-sdk prior to getting it audited. Ironically, the drama over this paper is now putting funding for the other audits at risk, however - as who wants to fund a project with a bunch of loud infosec folks declaring it shit?
      - shaldengeki 4y ago
        > Ironically, the drama over this paper is now putting funding for the other audits at risk, however - as who wants to fund a project with a bunch of loud infosec folks declaring it shit? I'm not familiar with how the funding here works - can you describe the process by which audits would be abandoned as a result of internet commentary? Who is threatening to withhold funding for future audits? From my outsider's perspective, that would seem like _incredibly_ poor decision-making on behalf of the Matrix folks.

Arathorn 4y ago

You are completely misinterpreting my quote, which makes me question whether you are acting in good faith. Totally agreed that Signal servers cannot just add a device to a group chat. What I saying was: in any system, you have to verify users for security in general. Having verified users in Matrix, you then get a massive red warning if an unverified device is added to their accounts. Given we have cross-signing (i.e. users are heavily encouraged to verify their own devices when they log in), you can be sure that such unverified devices are malicious and take appropriate action. The obvious thing we could do is to go one step further (as we used to, until we backed it out in https://github.com/matrix-org/matrix-react-sdk/pull/3837 https://github.com/matrix-org/matrix-react-sdk/pull/3837) and stop messages from flowing until the unverified device has been dealt with. Even better would be to make group membership controlled by the clients, so the server can't add devices at all. And we're working on this, as part of shifting the implementations over to the audited matrix-rust-sdk-crypto implementation to avoid having to solve the problem in quadruplicate. > I would challenge you to get one reputable cryptographer to back what you’re claiming about these vulnerabilities and your proposed fixes. Hopefully someone will pop up here and confirm that I'm not talking shit :) Failing that, you'll have to wait for the next Least Authority audit - we have another independent public audit queued once this wave of work finishes to address the "To me Matrix isn't secure" polemicists. You can see the last one (on the crypto layer, rather than the group membership layer) at https://matrix.org/blog/2022/05/16/independent-public-audit-of-vodozemac-a-native-rust-reference-implementation-of-matrix-end-to-end-encryption https://matrix.org/blog/2022/05/16/independent-public-audit-... fwiw.

cvwright 4y ago
It’s encouraging to hear that you’re getting an audit of the new approach. Reading over the new design doc for authenticating membership events, and the Github comments, it feels like this is a case for some sort of model checking or automated theorem proving. Manually verifying that the new system does everything we want seems… tough.
- tptacek 4y ago
  Here I'll point out that Matrix had audits commissioned prior to this research as well. Audits are a good thing, but one reason the previous audits didn't hit on this stuff is that the scope of the audit was sharply limited.
  - Arathorn 4y ago
    Totally agreed. We didn’t have the $ to do more than libolm at first, and then we did vodozemac in May. That one was the first of 4 planned audits, the rest of which go up the rest of the stack (respectively matrix-rust-sdk-crypto, matrix-rust-sdk, and then end-to-end across the whole stack). It is very frustrating we couldn’t do the rest of the stack sooner - and this hopefully explains why we are consolidating on matrix-rust-sdk prior to getting it audited. Ironically, the drama over this paper is now putting funding for the other audits at risk, however - as who wants to fund a project with a bunch of loud infosec folks declaring it shit?
    - shaldengeki 4y ago
      > Ironically, the drama over this paper is now putting funding for the other audits at risk, however - as who wants to fund a project with a bunch of loud infosec folks declaring it shit? I'm not familiar with how the funding here works - can you describe the process by which audits would be abandoned as a result of internet commentary? Who is threatening to withhold funding for future audits? From my outsider's perspective, that would seem like _incredibly_ poor decision-making on behalf of the Matrix folks.