Comment on Looking for a chat app with specific requirements
solrize@lemmy.ml 1 week ago
E2EE with large groups is a hassle because you have to do messy key changing protocols every time somene leaves the chat (since you want to invalidate their keys when they leave). If you don’t mind the server (self hosted) seeing the plaintext that’s a lot simpler. Tbh I’ve simply used nextcloud chat or irc for stuff like this. I can’t really recommend nextcloud for various reasons but it was easy for me to set up a chat when I wanted one, since I already had a nextcloud server. Matrix is supposed to be the post-IRC IRC so I’d check into it, but I haven’t used it so far. I’m of the impression that Matrix isn’t E2EE (the server can see the private stuff) but maybe I’m wrong.
litchralee@sh.itjust.works 1 week ago
I’m having trouble imagining what in Signal’s implementation of the Double Ratchet, or any part of RFC9420 Message Layer Security, would inherently require a client app. Perhaps you mean that there is no readily available browser-implemented API for carefully managing secrets? Even in that situation, all the libraries needed to implement the RFC can be compiled as WebAssembly or to JavaScript (with the assumption that the browser and OS are outside a malicious actor’s capabilities) and ran that way.
To be clear, I’m not suggesting Signal is perfect, and papers about problems found in Signal and other apps are readily found, like this one from last month. But with that said, it does appear that OP’s described use-case involving hundreds of users in group chats is very much not what Signal was designed for,.
solrize@lemmy.ml 1 week ago
Maybe you’re right and you could implement something like MLS in JS and/or WASM. I don’t know if those can open raw socket connections instead of using websockets. You’d need a raw socket connection to interoperate with other apps like Signal, but with websockets you could implement similar functionality non-interoperably, maybe even using a server side proxy to route to a Signal server (the proxy would never see plaintext).
There’s still the matter of making sure that the JS or WASM download isn’t tampered with. You have to trust the server that send it to you, which is in conflict with the E2EE notion of not trusting the server. There could possibly be a MITM attack by someone with a signed TLS certificate. Worst is if it’s served from a CDN. CDN’s have alway seemed to me like supply chain attacks waiting to happen.