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?
@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 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 $.
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.
@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 😵💫
@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.
@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.
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.
@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.
amd
in reply to Hilmar Gústafsson • • •Hilmar Gústafsson
in reply to amd • • •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.
The Matrix.org Foundation
in reply to Hilmar Gústafsson • • •Hilmar Gústafsson
in reply to The Matrix.org Foundation • • •The Matrix.org Foundation
in reply to Hilmar Gústafsson • • •Dmitry Borodaenko
in reply to Hilmar Gústafsson • • •Hilmar Gústafsson
in reply to Dmitry Borodaenko • • •Josh Simmons
in reply to Hilmar Gústafsson • • •Hilmar Gústafsson
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.
The Matrix.org Foundation
in reply to Hilmar Gústafsson • • •夜坂雅
in reply to Josh Simmons • • •The Matrix.org Foundation
in reply to 夜坂雅 • • •