We won’t be removing Element, as we mention Element specifically which uses vodozemac. The author claims that is not effected.
We don’t recommend every other matrix client which hasn’t had an audit, and we don’t believe that Matrix.org should be responsible for making sure unmaintained/hobby clients use the latest library (how could they anyway, the whole thing with decentralization). Those projects are not a part of Matrix.org and are not covered by their audits.
Should this post be revived? A new article by @soatok talks about cryptographic issues in Vodozemac. I can’t understand the article since I’m not a cryptographer so I will put it in this thread for relevance.
Seconding the removal. I don’t understand computer code but that article has enough “technical trash talk” that I am scared of any encryption matrix devs submit.
Unrelated, the few encrypted rooms I visited were public which defeats the point of encryption.
Although it is very tempting just to say “fxxk yes“, I think PG team, if decided to follow up on this “new“ issue, could reach out matrix for their response, and see if Matrix’s response/ remedy plan is acceptable.
Given a POC is already provided by @soatok, I think PG team should take it seriously.
Also given how poorly the Matrix team is performing (i.e. not telling ) in informing users / hosts / potential users about the protocol that each known client is using ( see Matrix.org - Clients , its nothing there). I don’t think Matrix should get an easy pass like last time.
If Matrix team is unable to remedy in timely manner, I think PG should de-list Matrix/ Element with an announcement as the service provides false sense of security to people, which could put users in higher threat model at risk.
Matrix did respond:
However, their response is flawed and a bit misleading. I added an addendum to my blog post to explain more: Cryptographic Issues in Matrix’s Rust Library Vodozemac - Dhole Moments
Still a lot better then for example Discord considering privacy, security and software freedom.
I want the Matrix / Element recommendation to be rescinded. The Matrix protocol is a fragile mess, lacks proper perfect forward secrecy, leaks stupid amounts of metadata, and is not meaningfully open.
Relevant comments from the GrapheneOS Foundation: https://xcancel.com/GrapheneOS/status/1879270157576782143#m
https://xcancel.com/GrapheneOS/status/1963101488898519414#m
The have partial forwards secrecy, right?
How do you mean this?
I read your blog post earlier today, so seems I am up-to-date, thats good.
I would prefer PG to reach them again, so they could have another chance to think before responding.
Sorry just to bug @team for reconsiderations.
Matrix is better thought of as a competitor to XMPP, not Discord, and a poor one at that. Everything Matrix does XMPP does better.
What’s the state of of XMPP E2EE protocols? Last I checked was maybe 2014, and back then it was mostly opt-in OTRv3 with its already borderline outdated crypto between two devices at a time, with extremely poor (if any) cross-device support and no E2EE for groups.
@soatok adviced against OMEMO two years ago and latest addenum is from then too Against XMPP+OMEMO - Dhole Moments
So what’s the current state of XMPP E2EE in terms of usability and security?
To clarify, I’m not endorsing XMPP + OMEMO in general, I just think that it is better than Matrix at federated E2EE IM. All the problems XMPP + OMEMO has, Matrix also has and more.
I was just commenting on the failures of Matrix to actually succeed as an XMPP killer. Perhaps a better word choice on my part would be “everything Matrix does XMPP does less bad”.
I strongly encourage everyone to just use Signal.
I think it’s important to remember that Matrix/Element is recommended under the social networks category and not the real time communication category. Obviously a reasonable level of security and privacy is desired, but it doesn’t need to be at the level of Signal or something for private chats (although of course that would be nice). If we’re thinking of removing Matrix because it isn’t as secure as Signal, we should be applying the same standard to Mastodon which is under the same category as Matrix/Element.
Personally, as a social network, I find Matrix/Element far more usable and less buggy than XMPP. It’s also far more widely used by FOSS projects.
Edit: Actually, I just noticed the title of this post. Sounds like it was recommended under RTC initially but is no longer. If folks want it to also be removed from the social networks category, they should probably create a separate thread.
This got me too but I think in reverse, I didn’t realize it’s currently recommended as a social network rather than RTC until you mentioned it. I’m still not a fan but I agree it’s a separate conversation entirely in that context.
I guess, why are they doubling down and not just saying good catch? Like checking against the identity is pretty much DH 101. David Wong quite literally says “check validity of public keys or expect bugs”.
The fact Signal didn’t check them is also non ideal. But Matrix mentions this as a whattaboutism. What’s most grating in their reply is that they say it’s not an issue, note that Signal didn’t patch a similar bug until last week, and then AFTER defending not checking it, they decide to patch it (and not even fully ack the risk)
It’s worth saying that in our private correspondence with the reporter we agreed to add the check as a defence-in-depth and to remove any doubt of whether this constitutes a vulnerability. The check will be added in a future vodozemac release.
If Signal decides to patch a similar vulnerability (which risk has not yet been assessed), then is Matrix still handwaving if it as though it has no risk at all? Defense in depth is not a debate, it’s required for secure applications.
I.e., software engineers deploy redundancy for production systems - not because we expect to deploy bad systems, but it provides failover strategy if an unknown occurs. And after enough time, those unknown grow larger with more complexity.
Either Signal patched a real vulnerability (risk not yet determined), and this no check in Matrix is definitely a vulnerability of at least some correlation; or Signal had no vulnerability and their patch was just pre-emptive and Matrix was right all along.
Now I’m curious: was the lack of the DH identity check in Signal exploitable in the same way as Matrix is?
I once tried self hosting matrix, and I also concur it was a bit of a PITA. I wanted to utilize bridges, but honestly ditched it in favor of a direct IRC hosted service when needed. For my limited time, I prefer to host simpler things.
This is the one use case I don’t terribly mind Matrix. Assuming public discussion of FOSS,
https://eprint.iacr.org/2019/1416.pdf#page=10 Section 2.5 paragraph 3
When users in a Signal group send encrypted messages to the group, they encrypt
and send the message to each group member, individually, with end-to-end encryption
There’s no group key exchange and Chuck offering zero-public key to each contact in group sets the shared key to 0 for them and the contact. Then, any contact who sends a group message will, due to the nature of group chats, send one copy of the message to Chuck, and that particular ciphertext will use key deterministically derived from the zero-shared key.
So to me it looks like it’s different in principle, that Chuck can’t meddle with other group members’ message keys, but it’s as bad in that the server can nonetheless decrypt Chuck-related ciphertexts, with the zero-derived message key.
For example?
The only thing that really bothers me with Matrix is that the clients I tested have no eassy option to view the public key’s of your contacts/people-on-server’s