Can End-to-End Encryption Be Hacked? Where the Real Risks Actually Are

Short answer: properly implemented end-to-end encryption (E2EE) is not broken by attacking the encryption itself. The realistic risks sit at the endpoints, the key exchange, and the implementation, not the cipher. When a video call protected by E2EE is compromised, the attacker almost certainly didn't crack the encryption algorithm. They bypassed it entirely, targeting something much closer to the user.

This matters because the question 'can end-to-end encryption be hacked?' is often answered either with false reassurance or exaggerated alarm. Neither serves the people who actually need to make security decisions. This article explains what E2EE genuinely protects, where the real attack surface lies, and what a well-designed system does to defend against each vector, using Digital Samba's implementation as a concrete worked example.

Table of contents

1. What end-to-end encryption actually protects
   
2. Can the encryption itself be broken?
   
3. Where E2EE actually gets attacked: the real threat model
   
4. How a well-designed E2EE system defends against this
   
5. The trade-off most people miss
   
6. E2EE isn't a silver bullet: a practical checklist
7. Conclusion
8. Frequently asked questions

What end-to-end encryption actually protects

E2EE means content is encrypted on the sender's device and decrypted only on the recipient's device. Every server or relay in between, including the service provider's own infrastructure, handles ciphertext it can't read. The keys exist only at the endpoints. The server never sees them.

In a video call, E2EE can cover media streams, screen sharing, chat messages, participant names, and whiteboard content, all of which sit within the encrypted boundary. What sits outside that boundary is metadata: the fact that a call happened, when it started and ended, and which accounts took part. Metadata isn't payload. It's routing and session information that the infrastructure needs to function, and E2EE doesn't protect it.

Server-side features that need access to content, such as recording, live transcription, and automated note-taking, can't function within a true E2EE session, because the server can't decrypt what it would need to process. That trade-off is real, and we cover it in more detail below.

For a deeper look at how E2EE works in WebRTC specifically, Digital Samba's article on the power of E2EE in WebRTC covers the underlying mechanics in full.

Can the encryption itself be broken?

Not realistically. Modern end-to-end encryption is built on AES, the symmetric cipher trusted to protect everything from online banking to classified data. In WebRTC, media is encrypted frame by frame using SFrame, an IETF standard, and AES-128 is the established key length for it: it's what the standard specifies and what production WebRTC implementations have used since the scheme's first deployment. Digital Samba follows that standard, using AES-128 in counter mode with HMAC-SHA256 authentication for media, and AES-256-GCM for longer-lived data such as chat and the key exchange itself. Brute-forcing an AES key, whether 128 or 256 bits, is computationally infeasible with current classical computing. This isn't a matter of it being slow. On any realistic timescale, it simply can't be done, and no practical attack against AES has been demonstrated.

The honest caveat is quantum computing. Grover's algorithm, if it ever ran on a large enough fault-tolerant quantum computer, would give a quadratic speedup for searching keys, which in effect halves a symmetric key's strength in bits. That's one reason media keys are ephemeral, generated per session and rotated, rather than long-lived, and why longer keys are used for data that persists. NIST published its first post-quantum cryptography standards in 2024; what's still ongoing is migration. None of this makes current E2EE imminently vulnerable. The quantum threat is a planning horizon: something to prepare for over the coming years, well before it could affect a call made today.

Where E2EE actually gets attacked: the real threat model

The question isn't whether E2EE can be broken. It's how someone gets around the protection it provides. In practice, attackers consistently go after the boundaries of the encrypted channel.

• Endpoint compromise is the most direct path. If malware or a keylogger is running on a participant's device, it can read content at the point of decryption, right after the encryption has done its job. E2EE can't protect against a device the attacker already controls: the encryption boundary ends at the device, and what happens on the device is outside its scope. This is why endpoint security is a precondition for E2EE, not an optional extra.
• Man-in-the-middle (MITM) attacks on key exchange are the classic theoretical attack on E2EE. The mechanism is straightforward: if an attacker can intercept the key exchange and substitute their own keys, they can position themselves between the two parties, decrypting and re-encrypting traffic in both directions. Each party believes they're communicating securely with the other; in reality, both are communicating securely with the attacker. The defence is out-of-band key verification, giving participants a way to confirm that the keys they're using are the keys their counterpart actually generated, without relying on the same channel that may be compromised.
• Implementation flaws are a more common source of real-world failure than either endpoint malware or active MITM attacks. Weak key generation, poor randomness sources, improper key storage, or a fallback path to unencrypted or weakly encrypted modes can undermine otherwise sound cryptographic choices. An implementation that 'supports E2EE' but doesn't enforce it, or that generates keys with insufficient entropy, offers much weaker protection than its marketing might suggest. The safeguard here is using audited implementations with no downgrade paths and no server-accessible copies of private keys.
• Social engineering and the human factor are frequently the easiest path of all. An attacker who can't break the encryption and can't compromise an endpoint may simply trick a legitimate participant into admitting them to the session, phish their credentials to pose as a valid user, or manipulate a meeting organiser into sharing screen content outside the call. Technical E2EE protects the channel. It can't protect the judgement of the people using it. The defence here is procedural rather than cryptographic: waiting rooms and admission controls, verifying an unfamiliar participant's identity out-of-band before letting them in, and training staff to recognise phishing attempts.
• Metadata leakage is a distinct concern from content protection. Even in a fully E2EE call, an observer with access to network traffic or service-provider logs can see that a call occurred, when, between which accounts, and for how long. For most professional contexts, this is an acceptable residual risk. For high-sensitivity use cases, such as legal proceedings, journalism, and clinical care, metadata visibility may itself be a concern that warrants additional controls.

How a well-designed E2EE system defends against this

The attack vectors above aren't insurmountable. A well-designed E2EE implementation addresses each of them architecturally. Here's what to look for in any E2EE product, using Digital Samba's implementation as a worked example.

Before getting into the architecture, one distinction matters: E2EE is a mode you switch on for a session, not the default state of every call. Every Digital Samba call is encrypted in transit, because WebRTC requires it. That transport encryption (TLS and DTLS-SRTP) works hop by hop, though, terminating at the media server as each stream is routed, which is what lets server-side features like recording work in the standard configuration. E2EE adds a further layer on top, encrypting the media itself end-to-end, so that once it's switched on the media servers only ever forward ciphertext they can't read. That end-to-end layer is the part you enable for a given session, and it's what the guarantees below depend on.

Keys are generated on-device using the Web Crypto API. Once E2EE is switched on, private keys are never transmitted to or stored on Digital Samba's servers: they exist only on the participant's device for the duration of that session. That's an architectural constraint, not simply a policy promise, and it holds for as long as the E2EE session runs.

To defend against MITM attacks on key exchange, Digital Samba generates a security verification code that participants can compare out-of-band, for example via a chat message, a phone call, or another channel independent of the video session. If the codes match, the key exchange hasn't been tampered with. If they don't match, that's a signal the session may have been intercepted. This mechanism is simple, requires no specialist knowledge to use, and directly addresses the most realistic active attack on E2EE key exchange.

That verification code rests on one assumption, though: that the code performing the encryption is itself trustworthy. Browser-based E2EE, Digital Samba's included, runs as JavaScript the browser downloads fresh each session, rather than a fixed, code-signed native app you install once, the way Signal or WhatsApp works. That is a genuinely different trust model. The same code that carries out the encryption also produces the verification code, so the code can't be used to check itself. This is an inherent property of doing cryptography in the browser, not something specific to any one provider, and it is why independent security audits, published cryptographic reviews, and transparent client code carry particular weight for browser-based E2EE. Those are what you rely on instead of taking the code on faith.

Forward and backward secrecy come from key rotation on join and leave events. When a participant joins, new keys are generated; when a participant leaves, keys rotate again. A key that's later compromised doesn't expose content from before it was generated or after it was rotated away. This limits exposure to the window between rotation events, rather than to the whole session.

Once E2EE is enabled, the SFU (Selective Forwarding Unit), which routes media between participants, handles ciphertext only. It can't decrypt the streams it forwards. That's built into the design: there's no setting that could override it while E2EE stays on.

The trade-off most people miss

That same guarantee, that the server never holds usable keys once E2EE is on, is also what makes E2EE incompatible with any feature that needs the server to read content. It's a trade-off that deserves to be said plainly rather than buried in documentation.

Recording and transcription, as typically implemented, need the server to access plaintext audio or video. In an E2EE session, where the server holds no keys, that's not possible. Choosing E2EE for a session means accepting that the call can't be recorded server-side, that automated transcription won't be available, and that compliance archiving depending on server-side capture won't function.

For many use cases, such as legal consultations, healthcare appointments, and sensitive business discussions, that's an acceptable and often desirable trade-off. For others, such as training recordings, customer support QA, and regulated-industry archiving, it may not be. The important thing is to make this choice deliberately, with an accurate understanding of what E2EE prevents on the server side, rather than discovering the incompatibility after deployment.

E2EE isn't a silver bullet: a practical checklist

Here's what genuine protection looks like in practice, and where the residual responsibilities sit:

• Keep endpoints patched and clean. E2EE protects the channel; it can't protect content read by malware before encryption or after decryption. Operating system updates, browser updates, and endpoint security all need to be in place for E2EE to mean anything.
• For sensitive calls, verify the security code. Out-of-band verification is the primary defence against key exchange manipulation. Building it into the workflow for sensitive sessions, even when it feels procedurally awkward, is the difference between E2EE that actually defends against MITM attacks and E2EE that merely claims to.
• Control who gets into the session. Social engineering, not cryptography, is often the easiest way in. Use waiting rooms and admission controls, verify an unfamiliar participant's identity out-of-band before letting them join, and don't treat a meeting link as proof of who someone is.
• Confirm every participant's browser supports the E2EE mode. Browser support for the underlying encryption APIs isn't uniform, so check that everyone in a sensitive call is actually covered rather than assuming E2EE applies to the whole group once it's switched on.
• Use audited platforms. Independent cryptographic audits surface implementation flaws that wouldn't otherwise be visible. The absence of a published audit is itself a meaningful signal.
• Understand what metadata is and isn't protected. Know what your service provider can observe about session patterns even when content is encrypted.
• Know your recording and transcription trade-off before you configure sessions. This decision should be made by policy, not discovered by accident.

Conclusion

The short answer, again: the cipher isn't going to be the weak point. Your device, your key verification habits, and the quality of the implementation will be. A well-designed E2EE system keeps keys on-device, provides out-of-band verification, enforces forward and backward secrecy through key rotation, and ensures the server handles only ciphertext once it's switched on. That combination addresses the realistic attack surface directly. What it can't do is protect a compromised endpoint, guarantee metadata privacy, vouch for the code delivering it in a browser, or enable server-side features that need plaintext access.

Choose platforms that are honest about these boundaries. The ones that name the trade-offs accurately, including where E2EE has to be switched on and what it costs you when you do, are usually the ones that have implemented the rest correctly too.

For the technical details of Digital Samba's approach, the security whitepaper covers the implementation in full. For the WebRTC-specific mechanics of E2EE, the power of E2EE in WebRTC is the companion piece to this article.

Frequently asked questions

Is end-to-end encryption actually safe?

Yes, when it's properly implemented and switched on for the session. E2EE protects content in transit by ensuring only endpoint devices hold the decryption keys. It doesn't protect against a compromised device, it doesn't hide metadata, and its strength depends on the quality of the implementation.

How can end-to-end encryption be compromised?

The most realistic paths are malware on a participant's device that reads content after decryption, a man-in-the-middle attack on the key exchange that substitutes the attacker's keys for the legitimate ones, implementation flaws such as weak key generation or a fallback to weaker encryption modes, and social engineering that tricks a legitimate user into granting an attacker access to the session. The encryption algorithm itself isn't a realistic target.

Can AES-256 encryption itself be broken?

Not with current classical computing. Brute-forcing an AES key, whether the 128-bit keys used for real-time media or the 256-bit keys used for longer-lived data, is computationally infeasible on any practical timescale. Quantum computing may eventually reduce the effective strength of symmetric ciphers, which is why NIST published its first post-quantum cryptography standards in 2024 and organisations are now working through migration. That remains a planning horizon rather than a present threat. AES, at both key lengths, stays the standard for strong symmetric encryption.

Does end-to-end encryption protect against malware on your device?

No. E2EE protects content between devices. Once content has been decrypted on a device, it's accessible to anything running on that device, including malware. Endpoint security, such as keeping devices patched or using reputable security software, is a prerequisite for E2EE to provide meaningful protection.

How can you verify that a video call is really end-to-end encrypted?

The most reliable method is out-of-band verification of the security code that a properly designed E2EE system generates from the shared keys. If both participants see the same code, the key exchange hasn't been tampered with. If the codes differ, the session may have been intercepted. This step should be part of standard practice for sensitive calls. Beyond that, look for platforms with published cryptographic audits and documented key management practices.

Does end-to-end encryption hide who you're talking to (metadata)?

No. Metadata, information about who called whom, when, for how long, and from which accounts, is typically visible to the service provider and may show up in network-level traffic analysis, even when the call's content is encrypted. E2EE protects the payload; it doesn't protect the routing and session information the infrastructure needs to function. High-sensitivity use cases may need additional controls to address metadata exposure.

References

1. Barker, E. (2020). Recommendation for key management, part 1: General (NIST Special Publication 800-57 Part 1 Revision 5). National Institute of Standards and Technology.
2. Bhargavan, K., Brzuska, C., Fournet, C., Green, M., Kohlweiss, M., & Zanella-Béguelin, S. (2016). Downgrade resilience in key-exchange protocols. Proceedings of the 37th IEEE Symposium on Security and Privacy, 506-525.
3. Grover, L. K. (1996). A fast quantum mechanical algorithm for database search. Proceedings of the 28th Annual ACM Symposium on the Theory of Computing, 212-219.
4. Marlinspike, M., & Perrin, T. (2016). The double ratchet algorithm [Specification]. Open Whisper Systems.
5. National Institute of Standards and Technology. (2024). Post-quantum cryptography standardization [Project overview]. NIST.
6. Rescorla, E. (2018). The Transport Layer Security (TLS) protocol version 1.3 (RFC 8446). Internet Engineering Task Force.
7. Unger, N., Dechand, S., Bonneau, J., Fahl, S., Perl, H., Goldberg, I., & Smith, M. (2015). SoK: Secure messaging. Proceedings of the 36th IEEE Symposium on Security and Privacy, 232-249.
8. W3C. (2017). Web Cryptography API [W3C Recommendation]. World Wide Web Consortium.
9. W3C. (2023). WebRTC 1.0: Real-time communication between browsers [W3C Recommendation]. World Wide Web Consortium.