Secure Messaging: Encrypted Chats and Decentralization
Encrypted messaging platforms are experiencing a resurgence.
Applications such as WhatsApp, iMessage, and Signal have set a standard for end-to-end encryption (E2EE). However, many depend on phone numbers, centralized servers, and significant metadata, including information about your conversations, timestamps, IP addresses, and devices used.
Vitalik Buterin recently addressed these issues in his post on X and made a donation. He suggests that the future of secure messaging involves permissionless account setups without the need for phone numbers or Know Your Customer (KYC) processes, alongside enhanced metadata privacy. He specifically mentioned Session and SimpleX, donating 128 Ether (ETH) to support their efforts.
Session exemplifies this model, combining E2E encryption with decentralization. It operates without a central message server, routes traffic through onion paths, and uses keys as user IDs instead of phone numbers.
Did you know? Forty-three percent of public WiFi users report data breaches due to common threats like man-in-the-middle attacks and packet sniffing on unencrypted traffic.
Message Storage in Session
Session utilizes public key identities for its architecture. Upon signup, a keypair is generated locally to create a Session ID without needing a phone number or email.
Messages traverse a network of service nodes via onion routing, ensuring no single node can identify both sender and recipient. (The settings reveal your message’s node path.) For offline delivery, messages are saved in small clusters of nodes called “swarms.” Each Session ID corresponds to a particular swarm where messages remain encrypted until retrieved by your client.
Historically, messages had a default lifespan of about two weeks in the swarm, after which only local copies would persist.
Yes, Session maintains a local database for chats and attachments, enabling you to scroll back for months or years. This results in an app download of about 60 to 80 MB, but the installed size increases as you send media, cache thumbnails, and retain chat history. Documentation and user reviews highlight the distinction between temporary network storage and lasting local storage.
You can manage this by deleting chats, utilizing disappearing messages, or clearing media. If visible, it still exists on your device.
Notifications in Fast Mode
The trade-off between privacy and user experience (UX) is evident in notifications.
On iOS, Session provides two modes:
Slow Mode employs background polling. The app intermittently wakes to check for new messages over its own network. This mode offers better privacy, though it may be delayed or unreliable depending on your OS’s background activity settings.
Fast Mode uses push notifications. Session utilizes Apple’s Push Notification Service on iOS and a similar method on Android for timely alerts.
The controversial aspect lies with Fast Mode. Per Session’s support documentation, opting for it means:
Your device’s IP address and push token are sent to an Apple-operated push server.
Your Session Account ID and push token are shared with a Session-operated push server to determine notification destinations.
Importantly:
Servers do not access message contents, which remain E2EE.
Session states that Apple and Google do not see your contacts or specific messaging timings beyond what their generic push infrastructure logs.
If this raises concerns, you have the option to switch to Slow Mode, though it may result in late or missed notifications—highlighting the choices users must navigate with decentralized messengers.
Governance, Transparency, and Information Requests
Changes have also occurred in Session’s governance.
Initially managed by the Australian nonprofit Oxen Privacy Tech Foundation (OPTF), stewardship transitioned to a new Swiss entity, the Session Technology Foundation (STF), in late 2024. OPTF’s last transparency report covers Q4 2024; subsequent requests will be handled and made available by the STF.
According to Session’s support documentation on information requests:
As Session is decentralized and E2EE, the foundation does not have special access to user messages or keys.
The STF publishes periodic transparency reports summarizing law enforcement requests and their outcomes.
This transparency record is likely what users envision when they mention a platform outlining government information requests, keeping a public log of inquiries and Session’s responses.
What realistically can be provided?
Potentially: Logs from websites, file servers, or systems they directly manage (like push relays or STUN/TURN servers), subject to Swiss law and relevant international requests.
Not: Decrypted messages or master keys to user chats, provided the implementation aligns with the protocol description.
Switzerland’s regime offers relatively lenient transparency compared to some jurisdictions, underscoring the importance of voluntary reports and technical data limits.
Put simply, while decentralization doesn’t prevent governmental inquiries, it limits what can be disclosed.
Did you know? Law enforcement’s infiltration of the EncroChat encrypted network led to the interception of over 115 million criminal messages from around 60,000 users, resulting in over 6,500 arrests and nearly 900 million euros in seized assets globally.
Concerns About Quantum Resistance, Calls, and the Ongoing Beta
The concern is with harvesting encrypted data now for future decryption. Adversaries can record encrypted traffic today and wait for tomorrow’s quantum computers to compromise current public key systems.
Session’s response has been a significant protocol redesign. In a recent blog post, the team introduced Session Protocol v2, which aims to incorporate:
Perfect forward secrecy featuring ephemeral keys.
Post-quantum key exchange through ML-KEM (formerly known as CRYSTALS-Kyber), a NIST-standardized method recently adopted by Signal’s PQXDH and Apple’s PQ3.
Is Session quantum resistant at present?
Not in the strictest sense. While development of v2 continues, it currently relies on classical elliptic curve cryptography. The roadmap indicates plans for hybrid post-quantum schemes; however, until these are executed, audited, and deployed across all clients, standard E2EE security should be expected.
Voice and video calls are another recurring issue. Session states:
Voice and video calls are available but function as a beta feature requiring user opt-in.
These currently rely on peer-to-peer WebRTC, which means your IP address is revealed to the other party and to a Session-operated STUN or TURN server for signaling and media relay.
Plans for onion-routed calls over Lokinet to hide IPs more effectively are in the works but are not implemented as the default yet.
Session’s blog and FAQ explicitly warn that users in highly sensitive situations should probably avoid enabling calls for the time being.
Therefore, the long beta period reflects the challenges of merging low-latency calls, onion routing, and robust anonymity measures.
The Impact of Decentralization on Users
Session encapsulates both the potential and the constraints of decentralized secure messaging.
Advantages include:
You can create an account without providing a phone number, email, or any identification, aligning with Buterin’s vision of permissionless account creation.
Messages navigate an onion-routed multi-node network, limiting the amount of metadata any individual operator can access or be compelled to log.
The shift of governance to Switzerland, coupled with open-source client use and transparency reports, may heighten public oversight regarding changes to the codebase or infrastructure.
However, decentralization does not equate to invisibility:
Local storage on your device poses a significant risk if it’s compromised or seized.
Fast Mode notifications and WebRTC calls can expose IP-level metadata to infrastructure providers, even if plaintext messages remain unseen.
Post-quantum security is still a planned feature until Protocol v2 is delivered and refined.
If you’re considering Session, it may be prudent to default to Slow Mode if metadata privacy is more critical than swift notifications. Leverage disappearing messages, and periodically cleanse old chats and media from your devices. The same caution applies to calls; if linking a Session ID to an IP address is concerning, it might be safer to keep voice and video features disabled until the calling infrastructure matures.
Broadly, E2EE alone is no longer sufficient. As government scrutiny on messaging apps intensifies and quantum threats transition from theory to reality, decentralization, metadata reduction, and post-quantum improvements are becoming essential components of secure messaging. Session is among several initiatives addressing these issues, each with its unique trade-offs, strengths, and limitations.
