Post AlmwIwyrcbJBcMhGLY by angdraug@mastodon.social
 (DIR) More posts by angdraug@mastodon.social
 (DIR) Post #Aljo9bbSLqGtbQtwrw by lihram@mastodon.online
       2024-09-06T08:58:38Z
       
       0 likes, 1 repeats
       
       Does anyone know who could tell me more about the current status in #matrix wrt what is e2ee and what is not?@matrix
       
 (DIR) Post #Aljq9a3CK7LghCzdC4 by adam@hax0rbana.social
       2024-09-06T20:57:50Z
       
       0 likes, 0 repeats
       
       @lihram @matrix I don't see any responses, so maybe I'll be the first.E2ee is optional in the protocol. I believe at least some servers require it for direct messages. Every room can have e2ee enabled.There will be a shield icon next to the room icon and clicking on the name of the room should pull up the setting where it will clearly indicate whether it's end-to-end encrypted. Different clients may vary in their UI, naturally.
       
 (DIR) Post #Alk0d4pjx2ie6hOzSK by lihram@mastodon.online
       2024-09-06T22:30:21Z
       
       0 likes, 0 repeats
       
       @amd @matrix 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.
       
 (DIR) Post #Alk0d5WdNZ1wFjTFJY by matrix@mastodon.matrix.org
       2024-09-06T22:53:36Z
       
       0 likes, 0 repeats
       
       @lihram @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 $.
       
 (DIR) Post #AlkqOd17lpODOl9tDM by lihram@mastodon.online
       2024-09-07T08:33:17Z
       
       0 likes, 0 repeats
       
       @matrix @amd Thanks! Do you have any info about e2ee user invites? Specifically, that was listed as one of the ways to remedy a malicious server craftong invites to a room. I haven’t been able to find whether that has been implemented yet.
       
 (DIR) Post #AllAOXNSjkRYzSqCoq by matrix@mastodon.matrix.org
       2024-09-07T12:17:32Z
       
       0 likes, 0 repeats
       
       @lihram @amd i think you’re asking about https://github.com/matrix-org/matrix-spec-proposals/blob/fayed/cryptographic-membership/proposals/3917-cryptographic-membership.md which is designed but not implemented yet (stuck behind fixing UTDs in general)
       
 (DIR) Post #AlmwIwyrcbJBcMhGLY by angdraug@mastodon.social
       2024-09-06T20:40:25Z
       
       0 likes, 0 repeats
       
       @lihram @matrix Not a direct answer, but has links to a lot of context that should help you qualify answers to your question: https://soatok.blog/2024/07/31/what-does-it-mean-to-be-a-signal-competitor/
       
 (DIR) Post #AlmwIy1NkiuuqSsmuW by lihram@mastodon.online
       2024-09-06T22:22:45Z
       
       0 likes, 0 repeats
       
       @angdraug @matrix 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 😵‍💫
       
 (DIR) Post #AlmwIyrqbestTBQggi by josh@josh.tel
       2024-09-06T22:25:21Z
       
       0 likes, 0 repeats
       
       @lihram @angdraug @matrix If the rabbit hole didn't include this, I definitely recommend checking it out: https://matrix.org/blog/2024/08/libolm-deprecation/
       
 (DIR) Post #AlmwIzOSeOyL6KgjWS by lihram@mastodon.online
       2024-09-08T07:41:46Z
       
       0 likes, 0 repeats
       
       @josh @angdraug @matrix 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: https://github.com/matrix-org/olm/issues/3I don't ascribe malicious intent to this, though. I understand it's mostly a bandwidth thing.
       
 (DIR) Post #AlmwIzycTxtauTbbsm by matrix@mastodon.matrix.org
       2024-09-08T08:49:04Z
       
       0 likes, 0 repeats
       
       @lihram @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.
       
 (DIR) Post #AlneHs1mwkUNwzMO48 by ShadowRZ@miruku.cafe
       2024-09-08T14:40:49.338Z
       
       0 likes, 0 repeats
       
       @josh@josh.tel @lihram@mastodon.online @angdraug@mastodon.social @matrix@mastodon.matrix.org 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.
       
 (DIR) Post #AlneHsZ6wr8zcKx00O by matrix@mastodon.matrix.org
       2024-09-08T17:01:58Z
       
       0 likes, 0 repeats
       
       @ShadowRZ @lihram @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.