Reviewing the cryptography used by Signal

Overall stance on Signal

  • Many commenters align with the article’s conclusion: Signal isn’t perfect but is currently the best practical private messenger for ordinary use.
  • Several report it has become their primary or only messenger in families, friend groups, daycare/parent chats, and some workplaces; in some regions it’s close to WhatsApp in prevalence.
  • Others say usage dropped sharply after SMS support was removed, especially where they had sold Signal as “a better SMS app” rather than “a separate secure messenger.”

Normalization, law, and threat models

  • Strong theme: using encrypted messengers must be normalized for mundane, legal use; otherwise, using them becomes incriminating metadata in itself.
  • Some argue strong post‑WW2 legal protections (e.g., in parts of Europe) mitigate risks; others counter that laws can be rapidly overridden by regime change, so relying on law is unsafe.
  • Distinction drawn between privacy and anonymity: Signal focuses on the former; high‑risk users should combine it with tools like Tor or even one‑time pads.

Signal vs XMPP/Telegram/WhatsApp/others

  • Critics: Signal’s centralized infrastructure and phone‑number requirement are fundamental flaws; self‑hosted XMPP/OMEMO or Telegram with third‑party clients are seen as more controllable.
  • Counterpoints:
    • Signal is free/open source and not “proprietary” in the usual sense.
    • XMPP/OMEMO is fragmented, often allows plaintext fallback, and doesn’t enforce latest protocol versions, making it unreliable for private communication.
    • UX and onboarding (especially for non‑technical users and remote relatives) are far easier with Signal than XMPP; Olvid is cited as cryptographically strong but practically unusable due to mandatory in‑person QR ceremonies.

Server trust, metadata, and crypto mechanisms

  • One camp insists “you can never trust the server,” emphasizing that Signal’s servers see IPs, timing, and can block delivery.
  • Others respond that Signal’s design (end‑to‑end encryption, Sealed Sender, zero‑knowledge group credentials, forthcoming key transparency) reduces the server’s role to availability:
    • Server cannot know who sent a given message, and cannot reliably map delivery tokens to specific users.
    • Selective censorship is claimed to be impossible beyond blindly dropping messages for unknown tokens.
  • Debate over whether this meaningfully hides contact graphs, given ISP logs and IP correlation.
  • Reproducible builds exist but are said not to be perfectly maintained.
  • A technical nitpick notes a keyed SHA‑256 construction in key transparency is currently safe but could constrain future evolution.

SMS, UX, and multi‑device

  • Removal of SMS is seen by some as a strategic mistake that hurt adoption where SMS is still heavily used; others argue mixed secure/insecure UI was dangerously confusing.
  • Complaints about limited multi‑device support (e.g., Chromebooks, video calls blocking text input).
  • Phone‑number‑based discovery is criticized as a privacy compromise; usernames and new discovery options are welcomed but seen as incomplete.

VPNs, Tor, and ISP trust (spurred by the article’s VPN criticism)

  • Some defend VPNs as a practical middle ground: good against local ISPs, employers, hotels, and basic censorship, even if they don’t provide anonymity.
  • Others stress VPNs are just “another ISP,” trivially suitable for intelligence agencies or data brokers; “no‑logs” claims and audits are viewed skeptically.
  • Discussion repeatedly returns to explicit threat modeling: VPNs may be fine for avoiding local creeps or mild censorship, but inadequate against serious state‑level adversaries.