Can End to End Encryption Be Hacked?

The short answer: the encryption itself, almost certainly not. Everything around it, routinely. If you're asking "can end to end encryption be hacked," you're asking the wrong question in the right direction. The cipher math is solid. The devices, the metadata, the product decisions, the backup policies, the contact-discovery APIs: those are where things break. This piece walks through each real attack surface, with specifics, so you can evaluate E2EE claims (ours included) with the skepticism they deserve.

Key Takeaways

• No practical attack has ever broken AES or the Signal Protocol's underlying cryptography. The actual attack surface is everything outside the ciphertext: endpoints, metadata, implementation choices, and political pressure.
• Endpoint compromise (malware, spyware, keyloggers) renders E2EE irrelevant because content is read after decryption on the device. Recent zero-click exploits prove this is not theoretical.
• Metadata (who talked to whom, when, how often, device fingerprints) is never covered by E2EE and is actively exploited at scale, including by law enforcement frameworks like Europol's.
• Product and business decisions, such as Meta removing E2EE from Instagram DMs or the UK ordering Apple to backdoor iCloud, can eliminate your E2EE protection overnight without touching the math.
• "Harvest now, decrypt later" means today's encrypted traffic is being collected for future quantum decryption. Post-quantum migration timelines are a real due-diligence question, not a theoretical one.

Has Anyone Ever Broken AES or the Signal Protocol Mathematically?

No. Security researchers consistently confirm that no practical attack has ever broken AES encryption itself. Brute-forcing a 256-bit AES key would take longer than the projected lifespan of the universe on any hardware that exists or is projected to exist in classical computing. The Signal Protocol, which underpins most modern E2EE messaging implementations, has survived years of academic scrutiny without a cryptographic break.

This is worth stating flatly because it frames everything that follows. When E2EE fails in practice, the cipher is never the component that failed. The real question is: what sits outside the encryption boundary?

What Are the Actual Attack Surfaces Around E2EE?

The encryption boundary ends at the device. Everything before encryption and after decryption is exposed. Everything adjacent to the ciphertext (routing data, timing, session metadata) was never encrypted in the first place. The attack surfaces fall into a few concrete categories, each worth examining on its own.

How Does Endpoint Compromise Defeat E2EE?

Completely. If an attacker controls your device, E2EE provides zero protection. A keylogger captures text before encryption. Screen-capture malware reads messages after decryption. Spyware with sufficient privileges can extract keys from memory. The encryption math is irrelevant because the attacker is sitting inside the trust boundary.

This is not hypothetical. In March 2025, Citizen Lab documented the Paragon spyware exploiting a vulnerability within WhatsApp that allowed zero-click device compromise. No user interaction required. The attacker gains access to the device, and from that point, every message is readable regardless of the encryption layer protecting it in transit. The E2EE was never broken. The endpoint was.

This class of attack is the most direct, the most effective, and the hardest for any encryption scheme to address, because the encryption was working exactly as designed. It protected data in transit. It was never designed to protect data on a compromised device.

What Can Metadata Reveal Even When Content Is Encrypted?

More than most people expect. E2EE protects message content. It does not protect the fact that a message was sent, who sent it, who received it, when, how often, from what device, or at what IP address. This is infrastructure metadata, and it exists because the network needs it to route messages.

A November 2025 study by researchers at the University of Vienna and SBA Research demonstrated this at scale. They showed that WhatsApp's contact-discovery feature could be abused to harvest data from roughly 3.5 billion accounts, including phone numbers, timestamps, profile photos, and even the public keys used for E2EE. Over 57% of those accounts had a publicly visible profile photo, and two-thirds of those photos contained recognizable human faces. None of this required breaking the encryption. The data was available because contact discovery, by design, requires some information to be accessible outside the encrypted channel.

Europol's 2025 Internet Organised Crime Threat Assessment names E2EE explicitly as an investigative obstacle, but its proposed workaround is instructive: rather than calling exclusively for encryption backdoors, Europol is pushing for expanded metadata-collection rules. They understand what we should understand. The metadata is often sufficient.

For AI products specifically, this is a particularly sharp problem. An AI assistant with E2E-encrypted content can still leak enormous signal through query timing, frequency, and payload size patterns. If an observer can see that you send a 4KB query every morning at 8am and receive a 12KB response, they know something about your behavior even with perfect content encryption. Mitigations exist (padding, batching, decoupling metadata from identity), but they require deliberate architectural choices beyond just "we use E2EE."

How Do Implementation Flaws Differ from Cryptographic Breaks?

A cryptographic break means the math is wrong. An implementation flaw means the math is fine but the software around it has a bug. In practice, implementation flaws are orders of magnitude more common and more exploitable.

Examples: a messaging app that falls back to unencrypted transport under certain network conditions. A key-exchange implementation with an off-by-one error that leaks partial key material. A backup system that stores plaintext copies of messages the user thought were encrypted. A Cornell research paper on injection attacks against E2E-encrypted applications showed that even with correct cryptographic primitives, application-layer logic could be exploited to manipulate encrypted data flows.

The WhatsApp contact-discovery vulnerability falls into this category. The Signal Protocol's cryptography was untouched. A feature built on top of it (contact discovery) exposed data that the encryption layer never covered. The distinction matters because it shifts the question from "is the encryption strong?" to "is the product well-built?"

Can Governments Force a Backdoor Into E2EE?

They're trying. And in some cases, succeeding in forcing the removal of E2EE rather than breaking it.

The UK government has repeatedly issued Technical Capability Notices demanding that Apple provide access to encrypted iCloud backups. The original order, issued in early 2025, demanded worldwide access. Because Apple doesn't hold the keys for its Advanced Data Protection (ADP) feature, compliance would have required fundamentally weakening the service. U.S. pressure led the UK to withdraw the worldwide demand, but a narrower order targeting British users followed in October 2025. Apple responded by removing ADP for UK users entirely and filing a second legal challenge at the Investigatory Powers Tribunal in mid-2026.

Apple's position is clear: it has never built and will never build a backdoor or master key. But the result for UK users is the same. They lost access to E2EE for iCloud backups. Not because the cryptography was broken, but because a government order made it untenable for the vendor to offer it.

The European Commission is expected to present a Technology Roadmap on encryption this year, evaluating "solutions" for lawful access to encrypted data while ostensibly preserving cybersecurity and fundamental rights. The tension between those goals is real and unresolved. Any system that provides lawful access to a third party is, by definition, not end-to-end encrypted between sender and recipient only.

Can a Vendor Simply Remove Your E2EE?

Yes. And it happens for business reasons, not just legal ones.

Meta announced it would discontinue E2EE support for Instagram DMs starting May 8, 2026, citing low opt-in rates. Users who want E2EE can use WhatsApp instead, Meta said, effectively redirecting an entire user base from one product to another based on an encryption feature decision.

This is a useful reminder. "Does this app offer E2EE?" is a snapshot, not a guarantee. It is a product decision made by a company, subject to change based on adoption metrics, regulatory pressure, or strategic priorities. The cryptographic capability exists or doesn't based on someone's product roadmap, and that roadmap can change with a blog post.

If your privacy model depends on a specific vendor continuing to offer E2EE, you're building on a decision that vendor can reverse. The protocol doesn't matter if the product ships without it.

What Is "Harvest Now, Decrypt Later" and Why Does It Matter Today?

It matters today because the data collection is happening today, even though the decryption capability doesn't exist yet.

"Harvest now, decrypt later" describes adversaries systematically intercepting and archiving encrypted data, holding it in reserve until cryptographically relevant quantum computers can break the encryption retroactively. The cost of storage is low. The value of certain data (state secrets, medical records, financial information, long-lived credentials) doesn't decay quickly. The calculus is straightforward: capture now, store cheaply, wait.

The timeline for "wait" is compressing. Three papers published between May 2025 and March 2026 reduced the estimated quantum resources needed to break RSA-2048 from 20 million qubits to fewer than one million, and potentially as low as 100,000 qubits. These are estimates, not working systems, but the trend line is moving in one direction.

NIST has already published post-quantum cryptography standards (FIPS-203, 204, and 205), and vendors are beginning implementation. The practical question for any product that uses E2EE is: when will you migrate to post-quantum key exchange, and what is your concrete timeline? This is a reasonable due-diligence question for any privacy vendor, and any vendor that can't answer it with specifics is telling you something about their roadmap.

Does E2EE Protect Against Social Engineering?

Not at all. E2EE authenticates the channel, not the person at the other end. If an attacker convinces you they're someone they're not, or convinces you to share your screen, or convinces you to export a conversation and email it, the encryption did its job perfectly. It encrypted a channel between you and an attacker.

The WhatsApp metadata research is relevant here too. Follow-on reporting through April 2026 described continued exploitation of the contact-discovery data for identity-based social engineering at scale. With a phone number, a face, a timestamp, and a public key, an attacker has enough to craft a convincing spear-phishing message. The content of your conversations remained encrypted. The metadata around them provided the targeting data.

What Should You Actually Evaluate When a Product Claims E2EE?

The claim "we use end-to-end encryption" is the start of the conversation, not the end. Here's what to look at:

• What exactly is E2E encrypted? Messages? Files? Voice? Video? Metadata? Backups? Contact graphs? Most products encrypt some of these and not others. The answer matters.
• Is E2EE on by default, or opt-in? Instagram's experience proved that opt-in E2EE reaches a small fraction of users. Default-off encryption is marketing material, not a security posture.
• Where do backups go? If encrypted messages are backed up in plaintext to a cloud provider, the E2EE protected the wire but not the data at rest. Apple's ADP dispute exists precisely because of this gap.
• What metadata is collected, and for how long? A "short retention window" for operational metadata is very different from indefinite metadata storage. Ask specifically.
• What happens to E2EE if the vendor changes its mind? Meta removed Instagram E2EE based on usage metrics. What structural or contractual commitment does the vendor make?
• What is the post-quantum migration plan? If the vendor says "we'll get to it," your data may already be in a harvest-now-decrypt-later archive by the time they do.

How Does This Apply to AI Products Specifically?

AI products have an E2EE problem that traditional messaging apps don't: inference requires processing plaintext.

A messaging app can encrypt a message on your device, transmit it encrypted, and decrypt it on the recipient's device. The server never sees plaintext. An AI assistant that runs on frontier models cannot do this for the inference step. At some point, the model needs to process your query, and that processing happens on hardware the AI vendor or its inference provider controls. This is a fundamental architectural constraint, not a design choice.

At Selina, we encrypt files and transfers (SelinaSEND) with zero-knowledge, end-to-end encryption. Memory is encrypted at rest, but a slice of each request reaches a frontier provider at inference, so memory is not end-to-end encrypted. We think stating this clearly is more useful than papering over it with vague claims. Non-content operational metadata is kept for a short retention window.

The honest framing for any AI product is: E2EE can protect data in transit and at rest, but the inference boundary is where encryption must, by current technology, be relaxed. What matters is how narrow that boundary is, what data crosses it, and what controls exist around the inference provider's handling of it.

Where Does This Leave Us?

E2EE is a necessary component of a privacy architecture. It is not a sufficient one. The cryptography is sound. The attack surfaces are everything else: the device, the metadata, the product decisions, the backup infrastructure, the legal environment, the vendor's willingness to keep shipping encryption when it's inconvenient.

Asking "can end to end encryption be hacked" is asking whether the lock on your front door can be picked. The answer is: probably not, if it's a good lock. But people also come in through windows, convince you to open the door, or get a court order compelling the landlord to hand over a key. The lock is the least likely point of failure.

Build your privacy model accordingly. Evaluate the entire system, not just the cipher suite. Demand specifics from vendors. And treat any claim that starts and ends with "we use E2EE" as the beginning of a question, not an answer.

Start a free 7-day trial, no card required, and see how we handle this in practice.

Michael C.

Founder & Principal Engineer, Selina Labs

Michael builds Selina, a privacy-first AI that remembers you across conversations. He ships security-sensitive AI in production — real attacks, real fixes, measured in minutes and dollars — and writes about privacy, security, and LLMs from that seat. Top Rated Plus and expert-verified on Upwork.

• www.upwork.com
• x.com
• medium.com
• selinalabs.io