E2EE is not TLS

Most teams that say "our data is encrypted" mean TLS in transit and encryption at rest. Both are real controls. Neither is end-to-end encryption, and the gap between them is the whole subject of this documentation.

TLS protects a connection. It terminates at your server. Your server decrypts, reads the plaintext, applies business logic, re-encrypts to storage with a key your infrastructure also holds, and re-encrypts to the next connection. Every one of those steps is intentional. The TLS design ends at the endpoint you operate because your server needs to read the message to do its job.

End-to-end encryption moves the endpoints. The two devices are the endpoints. Your infrastructure is in the middle.

The sending device encrypts content to keys that only receiving devices hold. The relay never needs message plaintext or device private keys. It still sees the envelope: who sent it, to whom, when, and how big it was. It does not need the inside.

Encryption at rest does not close the gap

Server-side encryption is often offered as the equivalent control. It is not, and the reason is narrow enough to state exactly: with encryption at rest, you hold the key. The key lives in your KMS, your environment, your IAM policy, your on-call engineer's session. An attacker who reaches your service reaches the thing that decrypts. The ciphertext and the key share a blast radius.

With end-to-end encryption, the private half of identityKeyPair and each derived message key exists on user devices. No configuration change or compromised admin credential can make stored relay envelopes readable. Compelled production access cannot make them readable either. The relay never held the material that opens them.

Why regulators care about the difference

Breach-notification law focuses on whether an attacker could understand the exposed data. That is where the architectural difference becomes a legal and operational difference.

• California Civil Code §1798.82. The notification duty attaches to unencrypted personal information. The law treats encrypted data as unencrypted if an attacker also gets the encryption key.
• The FTC Safeguards Rule. The notification event occurs when someone gets unencrypted customer information without authorization. Encrypted information counts as unencrypted if the attacker also accessed the key.
• GDPR Article 34(3)(a). Controllers can omit notice to affected data subjects under one condition. Applied protections must make personal data unintelligible to unauthorized people. Encryption is one example, and the protections must cover the affected data. Article 33 notification to the supervisory authority is a separate duty. The same provision does not waive it.

All three rules depend on whether the attacker also obtained the key. Server-side encryption puts the key in the same perimeter as the data. A full service compromise therefore defeats the exception. End-to-end encryption removes the key from your possession. You cannot disclose a key that your server never had. There is no server-side key custody to examine.

Say this accurately

This documentation is not legal advice, and nothing here substitutes for your counsel reading your facts. Two claims in particular are wrong and we will not make them:

Almost no regulation requires end-to-end encryption. Frameworks like HIPAA, SOC 2, and GDPR use controls and risk as their basis. They ask for appropriate protection, and they accept server-side encryption as appropriate in most contexts. Anyone who presents E2EE as a compliance requirement misstates the requirement.

End-to-end encryption is not compliance. It can reduce liability and the scope of a compliance review. It reduces what a breach can expose or a subpoena can extract because you do not hold the material. These are commercial arguments, not certifications.

Version note: the SDK is 0.1.x. Public APIs and persisted formats may change before 1.0.

Next

• How E2EE changes your architecture: the inventory of logic that has to move off the server.
• Limits and metadata: precisely what the relay still observes.
• Threat model: adversary classes and what the SDK does and does not defend against.
• Quickstart: two clients and one relay, running.