Skip to main content


But Soatok, if you agree that centralization is bad, why do you still recommend Signal?


Because Signal is the only app that currently implements E2EE correctly that isn't owned by Meta. (And WhatsApp isn't open source, so it's disqualified anyway.)

If you want people to use your "federated" or "decentralized" faves, they really need to step up their game on how cryptography is implemented. Matrix, XMPP, whatever. I will never recommend anything that isn't at least as secure as Signal is.

This entry was edited (4 weeks ago)
in reply to Soatok Dreamseeker

If the app in question uses RSA at all, it's disqualified.

If the app uses cipher agility in the same way that JWT does, it's disqualified.

If it uses non-AEAD modes for encryption, it better Encrypt-then-MAC and verify the tag (in constant-time) before decryption on the other end.

These are some basic things that disqualify a lot of homemade proposals. I imagine it will get even stupider with GenAI.

in reply to Soatok Dreamseeker

I hope #DeltaChat does these right because they're my favorite contender atm for "Signal but with multiple profiles and no phone number"
in reply to Soatok Dreamseeker

Fair enough. I hope that someone competent is working on something that can become that alternative option.
in reply to Soatok Dreamseeker

I just have a hard time caring all that much about encryption modes while my Signal account got a new key and none of my contacts noticed.
in reply to Soatok Dreamseeker

And you need to acknowledge that post-Snowden, leaking the shape of the connection graph to passive adversaries doing traffic monitoring on servers is an important part of your threat model. And so is leaking connectivity when one of your correspondents' servers is actively malicious.

And if you don't design your protocol around these being threats then it isn't a good fit for modern problems.

And that's not just a cryptography problem, that's a protocol problem that depends on good cryptography. Using 'the same crypto as Signal' doesn't help if the way that it's integrated with the protocol loses some of the security.

Soatok Dreamseeker reshared this.

in reply to Olivetree

This entry was edited (3 weeks ago)
in reply to David Chisnall (*Now with 50% more sarcasm!*)

@david_chisnall
Thank you for your response.
Server compromise and centralization is exactly the source of fear. Them being on AWS and GCP is not good at all. Censorship resistance is another related one, no one knew what would happen to Signal under Chat Control, that's a red flag for something that can plausibly happen.
Also, phone numbers did very little for my contacts to join Signal, people simply don't want to change apps. Sometimes they change, but drop it shortly after.
Any opinions on SimpleX? Looked better than Signal to me, privacy wise (and apart from some missing functionality and excluding anonimity set, but Signal didn't have that in the beginning as well), but I'm by no means an expert.
@soatok
in reply to Olivetree

in reply to David Chisnall (*Now with 50% more sarcasm!*)

@david_chisnall @olivetree They had a Trail of Bits audit at the end of 2024: github.com/simplex-chat/simple…

The findings were all medium at worst. That inspires some confidence.

in reply to Soatok Dreamseeker

This is a similar methodology to why GrapheneOS only supports Pixel phones. They have a list of basic requirement for what the phone hardware needs to be capable of on their site, and frankly none of the phone manufacturers other than the Pixel's meet the mark.

It's all well and good to have the best intentions with privacy and cryptography, but if you can't get the basics right, or you cut corners for simplicity, then your model has already failed.

If doing a ROT13 on all of your messages was a good enough approach, then we could all run around with Telegram or Meshtastic

[edit] I forgot to add the link to the GrapheneOS requirements (under "which devices will be supported in the future"): grapheneos.org/faq#supported-d…

This entry was edited (4 weeks ago)
in reply to Soatok Dreamseeker

yeah but you see it's easier for me to say you are a Signal shill than admit my threat model starts with admitting defeat.

God the comment section on Lobsters was unusually frustrating this time around.

in reply to Soatok Dreamseeker

The other crucial thing that few others get right is clean UI/UX. Getting my family to use Signal had almsot zero learning curve. A lot of the alternatives trade UI/UX for security, but Signal proves that you can have both
in reply to Phillip

@phillip
And this ties into anonymity sets. For a system to be useful for confidential communications the actually matter, you need a lot of traffic that looks the same flowing through the same or indistinguishable-to-an-adversary paths. Everyone who joins a system like this to share cat pictures with their family makes it safer for union organisers, whistleblowers, and so on. The kind of UI that makes this onboarding easy isn’t an optional extra, it’s a key security feature. And that’s where Signal’s discoverability via phone number really wins and why systems that say ‘look, no phone number required! We’re super private!’ End up with anonymity sets that are too small for anyone to hide in.
in reply to David Chisnall (*Now with 50% more sarcasm!*)

@david_chisnall I could potentially see a decentralized, no-KYC option that takes design decisions from TOR to at least mitigate easily-identifiable traffic. However, you still run up against the other challenges of decentralization, such as outdated/modded servers. Signal absolutely has its flaws, but the team clearly goes through serious discussion and iterates before landing on a well-balanced decision.
in reply to Phillip

@phillip @david_chisnall To this problem, I point to: soatok.blog/2024/08/28/introdu…
in reply to Soatok Dreamseeker

I read your blog post. Sorry for more question, but would a XMPP+Alacrity be possible if we completely replace omemo with your planned lib and not try to update omemo (which you already wrote doesn't work)
in reply to Soatok Dreamseeker

that's good enough for me. The details we have to see with the specific implementation of xmpp-client and server software.
in reply to Soatok Dreamseeker

I really like the idea of decentralization but current concepts will never be able to achieve the same security level and reliability since it requires shared state. And this itself is hard to do in a decentralized manner but it’s even more difficult when the state isn’t transparent to the servers in order to prevent information leakage. Some like Matrix have problems with split state and leakage and others like DeltaChat don’t even have a state.