Gregory's ServerPlease stop recommending Matrix in my mentions
I do not think the Matrix developers are competent enough to design a secure protocol
 35 comments
A more detailed write-up: https://gist.github.com/soatok/8aef6f67fec9c702f510ee24d19ef92b @cobratbq Last I heard, "eventually". If there's been movement there, it hasn't reached cryptography circles @soatok hmmm.. okay, Matrix might have said something at FOSDEM, but I don't recall details. Would be this talk, if anyone's interested. The description makes no direct ref. to MLS. @soatok I took a cryptography class as part of my cs degree but that's the extent of my knowledge. Do you have any suggestions for where I could learn more for my own personal curiosity? I know better than to roll my own cryptography for any project and I promise it's just for curiosity, lol   @soatok iirc they were actually trying to develop dMLS, decentralised MLS, and then planning to adopt that but that was a few years ago, and there was 1 person working on it, and i dont know if they're even allowed energy and time to work on that anymore @ShadowJonathan @soatok dMLS is Vectors attempt at bending MLS, specifically its requirement of having a linear commit history, to Matrix transport model which can't enforce that. @soatok@furry.engineer that's a good point, but have you considered this: @soatok I read that they want to switch to MLS, but the last time someone worked on it was July 2023. But they have to do adjust MLS to work with Matrix's architecture, so still enough room for mistakes.  @soatok also, every single client and server implementation has a bunch of usability issues and inconsistency that makes it really hard to recommend to anyone non technical, security aside. @zeh They've built a complex mess of Toxcore + Ed448 (biggest curve is best curve but with added NIST paranoia) + AES-GCM (which is maximally "we trust NIST") for bulk encryption, plus their own double ratchet implementation with their own NTRU implementation, with Haskell bindings! The only reason I suspect this hasn't collected any CVEs is because Haskell code is unreadable to anyone that isn't a biblical scholar in functional programming. @zeh If you want a more concrete security risk: How are they mitigating Invisible Salamanders? Because if they're not, lol  @colinstu Does XMPP default to plaintext even if both clients support the OMEMO extension? @colinstu My point is that, even with an optional extension like OMEMO, the XMPP protocol suite isn't really sitting at the big kids table with E2EE protocol designs and shouldn't be treated the same way. @colinstu Matrix didn't end up that way either ;P https://gist.github.com/soatok/8aef6f67fec9c702f510ee24d19ef92b  @soatok@furry.engineer Yep, this one is extremely horrifying. It gives me the impression of them absolutely not understanding what they're doing.  I'm glad someone is taking a shot at making an open version of discord, but I also am very aware that what they have made is incredibly resource heavy. I have my doubts as well, but I'm still in their corner if they can get it right.   @soatok they can't even get *unencrypted* chat working right, much less anything involving cryptography @soatok my assumption is that in 6 to 9 months when discord finally does something to piss me off and i need to find a new chat platform for treehouse that i am just going to pull a linus torvalds and take a month or two leave and just write something |
This isn't a personal attack, it's an observation of their inability to detect and mitigate this basic of a protocol security issue before a third party looked their way
Most people are not qualified to do this work! That's why Signal is the go-to recommendation for now