Comparison
Signal vs Session
Signal: The gold-standard E2EE messenger: open-source, independently studied, post-quantum, and run by a nonprofit that has proven in court it holds almost no data — but it still ties your account to a phone number and runs on central servers. · Session: A no-phone-number, onion-routed messenger that hides your IP and metadata by default — strong on anonymity, but its currently-shipping protocol still lacks forward secrecy.
Bottom line: For most people who want the strongest, most thoroughly vetted encryption, Signal is the safer default. Its protocol is the industry reference, it has shipped post-quantum protections to ordinary users, and the Signal Foundation has demonstrated in court that it holds almost no data to hand over. The price is a phone number tied to your account and a central operator you have to trust to behave (its open-source server code and minimal-data design are what make that trust reasonable).
Signal and Session both encrypt every conversation end-to-end by default and publish their source code, so the real differences aren't about whether your messages are encrypted — they're about identity, metadata, and the protocol's guarantees. Signal ties each account to a phone number and runs on its own central servers in the United States; Session needs no phone number or email at all and routes traffic through a decentralized onion network so that no single server sees both the origin and destination of a message. That trade defines the choice: Signal optimizes for a rigorously studied, battle-tested cryptographic core, while Session optimizes for anonymity and the absence of a real-world identifier.
The catch is that the two apps make opposite compromises under the hood. Signal's cryptography is the modern reference standard — X3DH plus the Double Ratchet, now extended with PQXDH for the handshake and the post-quantum SPQR / Triple Ratchet for ongoing messages — giving it forward secrecy, post-compromise security, and quantum resistance. Session, by contrast, hides far more metadata by default but its currently-shipping protocol still lacks forward secrecy: the Session team openly acknowledges this and is rebuilding it in a V2 protocol (which also adds post-quantum support) that is still in development. So the honest framing is anonymity-by-default versus cryptographic-guarantees-by-default.
The facts, side by side
| Signal | Session | |
|---|---|---|
| End-to-end encrypted by default | Yes | Yes |
| Encryption protocol | Signal Protocol: X3DH + Double Ratchet with AES-256-GCM, now extended by PQXDH (handshake) and the Triple Ratchet / SPQR (post-quantum ratchet) Signal's classic stack is X3DH key agreement + the Double Ratchet, with AES-256 in CBC/HMAC historically and AES-256-GCM AEAD. In 2023 Signal added PQXDH (X25519 + CRYSTALS-Kyber/ML-KEM-768) to the initial handshake, and on Oct 2, 2025 shipped the Sparse Post-Quantum Ratchet (SPQR), combining the Double Ratchet with an ML-KEM-768 ratchet into a hybrid 'Triple Ratchet.' | Session Protocol (libsodium: X25519 key exchange + AES-256-GCM AEAD; Ed25519 identity keys) Session migrated off the Signal Protocol to its own libsodium-based Session Protocol. The current shipping protocol notably lacks Perfect Forward Secrecy and cryptographic deniability; PFS is slated to be re-implemented in Protocol V2 (announced Dec 2025), which is not yet released. |
| Post-quantum key exchange | Yes Post-quantum protection is hybrid (classical + ML-KEM-768) and is being rolled out automatically; older clients downgrade gracefully when a peer lacks SPQR support, so coverage is universal at the handshake (PQXDH) and progressively universal for the ongoing ratchet (SPQR). | No Session's currently-shipping protocol (V1) contains NO post-quantum cryptography at all. Per Session's own documentation, V1 encrypts messages with X25519 ECDH + AES-256-GCM and has neither forward secrecy nor any PQ key exchange. Post-quantum (ML-KEM) is a feature of the as-yet-unreleased Session Protocol V2, which is still in design; a detailed spec is only promised for community review in 2026 and is not in the released app. 'partial' wrongly implies an opt-in or shipping PQ capability; the correct tri-state is 'no' (with a factNote that V2 plans to add ML-KEM-based PQ key exchange, targeted for spec release in 2026). This is also consistent with the entry's own oneLiner, which already concedes the currently-shipping protocol lacks forward secrecy. |
| Requires a phone number | Yes A working phone number that can receive an SMS/call is still mandatory to create an account. Usernames (added 2024) only let others reach you without seeing your number; they do not replace the number for registration. | No |
| Requires an email address | No | No |
| How you’re identified | Phone number is required to register; an optional username lets you be contacted without sharing the number | Random Account ID (Session ID): a 66-character hex string derived from an Ed25519/X25519 keypair generated on-device. Recovery via a 13-word seed phrase. No phone, email, or KYC. The Session ID is the long-term public identifier and is reused across all conversations, which has some metadata/linkability implications compared to per-conversation identifiers. |
| Architecture | centralized | onion-relay Not pure peer-to-peer and not a single central server. Messages are stored-and-forwarded through a permissionless, blockchain-incentivized network of community-run service nodes, reached via onion routing — closest to an onion-relay model. |
| Metadata protection | Sealed sender hides the sender from Signal's servers; private contact discovery and encrypted profiles/groups minimize what the server can see, but a central server still routes all traffic Sealed sender gives one-way sender anonymity from the server, and private contact discovery plus SGX-backed features reduce server knowledge. Government subpoenas (2016, 2021) confirmed Signal could only produce account-creation and last-connection timestamps. However, a central server still sees connection metadata such as IP and timing, which is why it is 'centralized' rather than a metadata-minimal P2P design. | Strong: onion-routed by default through a decentralized service-node network (onion requests), hiding sender IP; no central account directory; project states it collects no metadata, geolocation, or device/network data. |
| Routes over Tor by default | No Signal does NOT route over Tor by default. It offers censorship circumvention (domain fronting / proxy support) when blocked, and users can manually run it through Tor/Orbot, but normal traffic goes to Signal's servers directly. | No Session does NOT use Tor. It uses its own Tor-like onion-routing system ('onion requests') over its decentralized Session Network service nodes (formerly the Oxen/Lokinet network). Onion routing IS on by default, but it is a separate network from Tor. |
| Open-source client | Yes | Yes |
| Independently audited | Partial Marked partial: the Signal Protocol has strong academic formal-analysis pedigree (e.g., Cohn-Gordon et al., IEEE EuroS&P 2017) and PQXDH received formal verification, but these are protocol/cryptography analyses rather than recurring full-stack commercial penetration audits of every client. Signal is exceptionally well-scrutinized for a messenger; 'partial' reflects that it is not a single, recent, end-to-end commercial audit of all apps. | Yes Audited by Quarkslab in 2021, covering the desktop, Android, and iOS clients. The newer Protocol V2 / post-quantum and PFS work has not yet been independently audited as of early 2026. |
| Jurisdiction / who can be subpoenaed | United States (Signal Foundation / Signal Messenger LLC, 501(c)(3) nonprofit, California) | Switzerland (Session Technology Foundation), relocated from Australia in 2024 The Session Technology Foundation was established in Switzerland in 2024 after the prior Australian steward (OPTF) stepped back, reportedly amid Australian law-enforcement and e-safety pressure on encrypted apps. |
| On-device duress / panic defenses | No Signal supports disappearing messages, a Signal PIN, registration lock, and screen lock, but has no built-in duress/decoy PIN or panic-wipe; a community feature request for a duress wipe was declined by Signal. | No Session offers a screen-lock/PIN and a recovery-password model, but no documented duress-PIN decoy vault or panic-wipe feature comparable to RVNT's. |
| Max attachment size | ~100 MB per attachment (varies by platform: ~100 MB Android/Desktop, smaller on iOS) Commonly cited as ~100 MB per attachment, with per-platform variation (Android/Desktop near 100 MB, iOS images notably smaller). Limits change over time; treat as approximate. | 10 MB |
| Collects telemetry / analytics | No Signal is funded by donations/grants, runs no ads, and does not monetize data. Subpoena responses demonstrate it does not retain message content, contacts, or profile data; it is widely regarded as not running analytics/telemetry on users. | No |
The verdict
For most people who want the strongest, most thoroughly vetted encryption, Signal is the safer default. Its protocol is the industry reference, it has shipped post-quantum protections to ordinary users, and the Signal Foundation has demonstrated in court that it holds almost no data to hand over. The price is a phone number tied to your account and a central operator you have to trust to behave (its open-source server code and minimal-data design are what make that trust reasonable).
Choose Session if not having any phone number or identifier is your top priority and you specifically want your IP address and metadata hidden by onion routing — for example, for whistleblowing or operating under surveillance where linking an account to a real-world number is the threat. Just go in clear-eyed that, until its V2 protocol ships, Session does not provide forward secrecy, so a future compromise of your long-term key could expose past messages in a way it cannot on Signal.
If you want to push further than either — no phone number and no central servers holding your content at all — a fully peer-to-peer, post-quantum design like RVNT sits in a more privacy-maximal next tier, though as newer software it hasn't earned the years of independent scrutiny that make Signal the established benchmark.
Frequently asked questions
Is Signal or Session better at hiding metadata and my identity?
Session hides more by default. It requires **no phone number or email**, so your account isn't linked to a real-world identity, and it routes messages through a decentralized **onion network** so no single server sees both who sent a message and who received it. Signal also minimizes metadata — it uses sealed sender and has proven in court it holds almost nothing — but it still requires a **phone number** to register and runs on its own central servers, which means there is an identifier and an operator in the picture.
Does Session have the same encryption guarantees as Signal?
Not yet. Both are end-to-end encrypted by default, but Signal's protocol provides **forward secrecy, post-compromise security, and post-quantum protection** (via PQXDH and the SPQR/Triple Ratchet). Session's **currently-shipping protocol lacks forward secrecy**, meaning a future compromise of your long-term key could expose past messages. Session's developers openly acknowledge this and plan to re-add forward secrecy and post-quantum support in a V2 protocol that is still under development.
Comparisons here are kept honest and dated — we name where the other app wins. RVNT is the post-quantum, peer-to-peer option with no phone number and no servers.