Decoding Signal: Understanding the Real Privacy Guarantees of E2EE

Decoding Signal: Understanding the Real Privacy Guarantees of E2EE

Speaker: Ibrahim (Security Engineer, independent researcher; in close collaboration with Signal)

Conference: Black Hat USA 2025 — August 6-7, 2025, Mandalay Bay, Las Vegas

YouTube: https://www.youtube.com/watch?v=CxnBO2gxMyI

Reading time: 9 minutes

Type: Briefing

TL;DR

A 15-year veteran security engineer conducted a comprehensive, collaborative security review of Signal — one of the few messaging applications that fully implements encrypted profiles, the double ratchet protocol, and sealed sender. He found and disclosed multiple vulnerabilities: an iOS client that accepted and processed unencrypted plaintext messages (including injected data messages), an Android client that processed plaintext envelopes without validating their content type, and — most critically — an Android flaw that allowed any user to send spoofed sync messages to another user's linked devices, enabling configuration tampering and message injection. The sync message bug was awarded a CVE with a score of 8.5 against the Whisperfish downstream client.

Introduction

Signal is widely considered the gold standard of secure messaging, and for good reason: it is one of the only applications with more than 10 million users that implements all three layers of privacy infrastructure — the Signal double ratchet protocol for forward and backward secrecy, end-to-end encrypted profiles, and sealed sender to hide metadata about who is communicating with whom. Most competing applications implement one or two of these features, if any.

But "gold standard" does not mean "perfect." Ibrahim, a security engineer with 15 years of experience, spent extended time reviewing Signal's entire client and server stack — all of which is open source — in close collaboration with the Signal engineering team. The result was a detailed security engineering report covering design, implementation, and execution-level vulnerabilities across iOS, Android, and desktop clients.

The talk is notable not just for the bugs found, but for what they reveal: the gap between a cryptographic protocol's theoretical guarantees and the real-world security a client implementation actually delivers.

▶ Watch: Introduction and Review Methodology (00:00)

How Signal's Cryptographic Architecture Works

Ibrahim walked through Signal's layered design using a physical mail analogy. In a standard mail system, the carrier can see both the sender and recipient and read the letter's contents. Signal's architecture aims to reveal as little of this information as possible to the server.

Profile encryption. Signal encrypts user profile data — name, photo, status, and any plaintext metadata — using a profile key generated on the client and never shared with the server. The data is stored server-side as an opaque AES-256-GCM encrypted blob. The profile key is only shared with contacts when a conversation begins, and only shared with an incoming contact after the user replies. Ibrahim attempted multiple techniques to leak the profile key from the server and was unable to do so.

Key agreement via X3DH. To establish an encrypted session, Signal uses elliptic curve Diffie-Hellman (ECDH) with ephemeral pre-keys. These one-time keys are uploaded to the server and consumed during session establishment. They are signed by a long-lived identity key, which is the most critical key in the entire system — compromising it allows impersonation.

Forward and backward secrecy via the double ratchet. Every message is encrypted with a unique key derived by running a chain key through a key derivation function. The message key is discarded immediately after use. If a device is compromised, the attacker cannot reverse the ratchet to decrypt prior messages (backward secrecy). If the conversation changes direction — when Bob replies to Alice — the ratchet resets with new Diffie-Hellman material, limiting forward exposure (forward secrecy).

Sealed sender. Introduced in 2018, this feature encrypts the "from" field of every message envelope, so the Signal server cannot determine who is sending a message to whom. The server only knows the recipient, not the sender.

▶ Watch: Signal Cryptographic Architecture Deep Dive (10:00)

Vulnerability 1: iOS Accepts and Processes Plaintext Envelopes

Signal's wire protocol defines three envelope types: ciphertext (a standard double-ratchet encrypted message), pre-key bundle (the first message establishing a session), and unidentified sender (sealed-sender messages). There is also a plaintext content type — but this is intended only for a specific error reporting case: decryption error notifications, which must be sent in the clear because the session keys may be in an inconsistent state.

Reviewing the iOS client code, Ibrahim found no validation on plaintext envelope content. The iOS client received a plaintext envelope, checked no type constraints, and processed whatever content was inside it — including data messages (normal chat messages). A malicious server, or an attacker who had compromised the server or performed a SIM swap to authenticate as the victim, could inject an arbitrary message into any conversation thread on the iOS client simply by sending a plaintext envelope.

"iOS clients can receive plain text envelopes from the server. It assumes the server is malicious, and the server can send plain text envelopes. It will receive these messages, process them, and it works," Ibrahim explained.

The impact extended beyond message injection: the same path allowed sending any of the 11 supported content subtypes, including sync messages that update client state.

▶ Watch: iOS Plaintext Envelope Vulnerability (18:01)

Vulnerability 2: Android Plaintext Envelope Missing Data Message Check

The Android client had validation logic for plaintext envelopes — it checked that a decryption error message was present and that certain content subtypes (story messages, edit messages) were absent. However, the code missed one critical check: it did not validate that data messages were absent from plaintext envelopes.

The execution order made this exploitable. Android parsed and executed content in a when block that processed data messages first. A plaintext envelope could contain both a decryption error message (satisfying the existing check) and a data message, and Android would execute the data message. This allowed a malicious server to inject messages into Android clients through the plaintext fallback path.

"This is still a bug, not necessarily a vulnerability, depending on the execution of the code," Ibrahim noted — but the execution order analysis confirmed the data message was processed.

Desktop also had incomplete validation but handled execution order safely: it processed the decryption error message first and returned inside each if block, preventing subsequent content from executing even if present.

▶ Watch: Android and Desktop Plaintext Envelope Analysis (20:01)

Vulnerability 3: Android Accepts Sync Messages from Any Sender

The most significant vulnerability involved Signal's linked-device synchronization mechanism. When a user has Signal installed on multiple devices — a phone and a desktop, for example — the devices stay in sync through a special invisible conversation. When Alice sends a message from her phone, her phone also sends a "sync message" to her own desktop, encrypted with the standard Signal protocol, informing it of the sent message and updating its state. Sync messages can carry 22 different payload types, including sent message records, contact list updates, read receipt configuration, typing indicator settings, and edit actions.

For security, clients must validate two things when receiving a sync message: that the envelope is encrypted (not plaintext), and that the message originated from the same account — i.e., from the user themselves, not from any other user.

Android's handleIncomingEnvelope function did not enforce the sender identity check. Any Signal user could send a sync message to any other Android user's account and have it processed as if it came from that user's own devices. Even users without linked devices were affected, because the sync message processing code executed unconditionally.

Ibrahim demonstrated the exploit live: by sending a crafted sync message, he changed the recipient's "read receipts" setting from enabled to disabled on their Android device in real time. The full range of 22 sync message types was exploitable, including injecting sent messages into conversation threads and marking contacts as verified.

The vulnerability was patched immediately upon disclosure — same-day response from Signal in September 2024. The downstream client Whisperfish was also affected and issued a CVE with a score of 8.5. Signal's three-month forced-update policy means no vulnerable clients should remain in production.

▶ Watch: Linked Device Sync Message Vulnerability and Demo (26:01)

What the Review Did Not Find

Ibrahim devoted time to discussing what he looked for and did not find. Signal's cross-platform library is written in Rust — one of the few messaging applications to use a memory-safe language for its core cryptographic library. Ibrahim found no memory corruption issues even in the portions of code written in unmanaged languages.

He also reported finding no logic-based or product-specific vulnerabilities beyond those described. The Signal codebase is notably lean: at roughly 300–500K lines of code for the client applications, it is 40–60% smaller than comparable messaging applications Ibrahim has reviewed. The minimal attack surface reflects deliberate design discipline.

Of the applications with more than 10 million users that Ibrahim examined, only Signal implemented all three privacy layers: the double ratchet, encrypted profiles, and sealed sender. Zero others implemented all three.

▶ Watch: Code Size, Language Stack, and Trust Model (06:00)

Notable Quotes

"Signal is one of the few applications where the library is written in Rust and not in other languages or memory-unmanaged language." — Ibrahim [06:00]

"iOS clients can receive plain text envelopes from the server. It assumes the server is malicious and the server can send plain text envelopes. It will receive these messages, process them, and it works." — Ibrahim [18:01]

"This also affects Android clients even if they don't have a linked device, because the code's just there, and the code will execute." — Ibrahim [30:02]

"I only looked at applications that have more than ten million users. None of the applications I noticed actually implemented encrypted profile or sealed sender." — Ibrahim [16:01]

Key Takeaways

• iOS lacked plaintext envelope validation entirely: A malicious server or SIM-swapped attacker could inject arbitrary messages into any conversation on iOS, including sync messages that alter app state.
• Android's plaintext validation missed data messages: Incomplete type-checking left a path open for server-injected data messages via the plaintext fallback, due to execution-order behavior in the when block.
• Sync message sender validation was absent on Android: Any Signal user could spoof sync messages to any Android account, enabling message injection, contact manipulation, and configuration tampering — including on devices with no linked device configured.
• Signal's architectural choices are genuinely differentiated: The Rust-based cross-platform library, lean codebase, encrypted profiles, and sealed sender implementation distinguish Signal from every other major messaging application examined.
• Coordinated disclosure works: All vulnerabilities were patched promptly — the sync message flaw same-day — demonstrating that Signal's open-source, collaborative model enables rapid response when researchers engage the team.

Slides

No slides PDF was available for this briefing.