Skip to main content


Does anyone know who could tell me more about the current status in #matrix wrt what is e2ee and what is not?

@matrix

in reply to Hilmar Gústafsson

Are you asking when it is enabled and when it is not or are you asking about what metadata is encrypted alongside the message and what is sent unencrypted?
in reply to amd

@amd Thanks for asking! I am curious about what is encrypted when e2ee is enabled.
I’ve been discussing the vulnerability disclosure from 2022 with others here on fedi, and was curious about the state of e2ee for user invites to rooms, but couldn’t find anything that summarized what is encrypted and what isn’t.
@amd
in reply to Hilmar Gústafsson

@amd message contents, message type and file contents in private rooms is e2ee. metadata isn’t: sender, timestamp, room id. stuff that the server needs to see to aggregate is also not e2ee: whether a msg was a reaction (& what the reaction was), whether it’s an edit or reply or thread (& to what msg). room state (room name, topic, avatar, membership) is not e2ee yet either. the plan to improve this is basically arewep2pyet.com, but stalled due to lack of $.
@amd
in reply to The Matrix.org Foundation

Thanks! Do you have any info about e2ee user invites? Specifically, that was listed as one of the ways to remedy a malicious server crafting invites to a room. I haven’t been able to find whether that has been implemented yet.
This entry was edited (2 months ago)
in reply to Hilmar Gústafsson

@amd i think you’re asking about github.com/matrix-org/matrix-s… which is designed but not implemented yet (stuck behind fixing UTDs in general)
@amd
in reply to Hilmar Gústafsson

Not a direct answer, but has links to a lot of context that should help you qualify answers to your question: soatok.blog/2024/07/31/what-do…
in reply to Dmitry Borodaenko

@angdraug Oof, that was quite the rabbit hole. 😅 I read the followup post about the Matrix vulnerability disclosure that includes a side channel attack they intentionally did not fix. Eek 😵‍💫
in reply to Josh Simmons

@josh @angdraug Thanks! Yeah, I had a look at that as well. The thing that bothered me is that this side-channel vulnerability has been known since at least 2017: github.com/matrix-org/olm/issu…

I don't ascribe malicious intent to this, though. I understand it's mostly a bandwidth thing.

in reply to Hilmar Gústafsson

@josh @angdraug it was entirely “this isn’t great, but there isn’t a way to exploit it. let’s focus in making the encryption work reliably, and then switch primitives - which we did by moving to vodozemac 2 years ago”. the biggest fail is not deprecating libolm earlier and more clearly.
in reply to Josh Simmons

One thing I'm curious but did't find the answer: Is there any reason that the particular crypto primitives was chosen at the start of libolm development? The most logical thing I can thought of is that WASM didn't exist in 2016 and there aren't any viable, safer alternatives that can be used in libolm during that time.
in reply to 夜坂雅

@ShadowRZ @angdraug @josh just because they were pure C, would compile down to asm.js via emscripten (this was 2015 and pre-wasm), and were functionally correct. and also because exploiting timing attacks remotely over Matrix is at best theoretical. however, we always knew it was (very) bad practice though, which is why we eventually solved it by switching to rust with vodozemac in 2022.