4 ms·

Do you have more info about the issues with Matrix?

MattJ100 3y ago
https://nebuchadnezzar-megolm.github.io/ https://nebuchadnezzar-megolm.github.io/ has details of the main issues I recall (most/all fixed as I understand it).
Arathorn 3y ago
He’s talking about https://nebuchadnezzar-megolm.github.io/ https://nebuchadnezzar-megolm.github.io/ - and the fact that group membership in Matrix is currently determined by the server rather than a client. So if Alice is in a DM with Bob, Bob’s server could make up malicious devices for Bob, or fabricate an invite to add Charlie to the room. This is mitigated by encouraging users to verify devices, so Bob’s fake device would be recognised as an attacker - and for faked invites, relying on Alice and Bob spotting that an unexpected malicious user just joined their conversation. However, it could be better: first we have been converging on a single Rust crypto impl (at last) - see the crypto section of https://matrix.org/blog/2023/12/25/the-matrix-holiday-update-2023/ https://matrix.org/blog/2023/12/25/the-matrix-holiday-update.... Then we’re shifting to TOFU (so unsigned devices never get encrypted for). Then, finally, we’re shifting to client-constrained group membership (unless MIMI gets there first, and then we may switch horses to their MLS-based solution). edit: the other issues raised by the nebuchadnezzar paper were impl bugs in the 1st gen crypto impls, which were fixed at the time. also, the premise that you can’t add encryption posthoc to a protocol is flawed, imo. Matrix may not have nailed it, but as long as you consider the crypto as if it’s a new protocol and have the agility to evolve to it, everyone wins. edit 2: there is no centralised db of who talks to who in Matrix. individual servers can see who shares a conversation which their server participates in, but this is very hard to avoid given you could always figure it out via traffic analysis (unless you go down a Nym style mixnet solution).
- tptacek 3y ago
  Regarding the database, I am thinking of systems like Wire. I don't know how Matrix handles buddy lists.

https://nebuchadnezzar-megolm.github.io/ https://nebuchadnezzar-megolm.github.io/ has details of the main issues I recall (most/all fixed as I understand it).

Arathorn 3y ago

He’s talking about https://nebuchadnezzar-megolm.github.io/ https://nebuchadnezzar-megolm.github.io/ - and the fact that group membership in Matrix is currently determined by the server rather than a client. So if Alice is in a DM with Bob, Bob’s server could make up malicious devices for Bob, or fabricate an invite to add Charlie to the room. This is mitigated by encouraging users to verify devices, so Bob’s fake device would be recognised as an attacker - and for faked invites, relying on Alice and Bob spotting that an unexpected malicious user just joined their conversation. However, it could be better: first we have been converging on a single Rust crypto impl (at last) - see the crypto section of https://matrix.org/blog/2023/12/25/the-matrix-holiday-update-2023/ https://matrix.org/blog/2023/12/25/the-matrix-holiday-update.... Then we’re shifting to TOFU (so unsigned devices never get encrypted for). Then, finally, we’re shifting to client-constrained group membership (unless MIMI gets there first, and then we may switch horses to their MLS-based solution). edit: the other issues raised by the nebuchadnezzar paper were impl bugs in the 1st gen crypto impls, which were fixed at the time. also, the premise that you can’t add encryption posthoc to a protocol is flawed, imo. Matrix may not have nailed it, but as long as you consider the crypto as if it’s a new protocol and have the agility to evolve to it, everyone wins. edit 2: there is no centralised db of who talks to who in Matrix. individual servers can see who shares a conversation which their server participates in, but this is very hard to avoid given you could always figure it out via traffic analysis (unless you go down a Nym style mixnet solution).

tptacek 3y ago
Regarding the database, I am thinking of systems like Wire. I don't know how Matrix handles buddy lists.