Glossary Terms

What is end-to-end encryption?

End‑to‑end encryption (E2EE) ensures that only the data owner and the intended recipient can decrypt content. Data is encrypted on the originating device, remains encrypted in transit and at rest, and is decrypted only by an endpoint that holds the appropriate key. Service‑side systems can route, store, and manage the data, but cannot read its contents when they do not possess the decryption keys.

In other words, E2EE converts readable information (plaintext) into ciphertext using keys that are controlled at the endpoints, not by intermediaries. If ciphertext is intercepted or stolen without the decryption key, it is computationally infeasible to recover the plaintext.

Clarification: Some services encrypt data in transit (TLS) and at rest (server‑side encryption) while keeping keys under provider control. That is not E2EE. The defining difference is who controls decryption keys.

How end-to-end encryption works (at a glance)

Encrypt on the sender’s device
The app encrypts the data before it leaves the device, typically using a fast symmetric cipher (e.g., AES‑256‑GCM or ChaCha20‑Poly1305). Keys may be derived from a passphrase or generated per session/backup.
Transmit ciphertext
The encrypted data is transmitted over the network. TLS is still used to protect against active network attacks, but confidentiality does not depend on TLS alone because the payload itself is encrypted.
Authenticate and verify integrity
E2EE schemes include authentication (digital signatures) and/or authenticated encryption (AEAD) to detect tampering. If a single bit changes, integrity checks fail and the data is rejected.
Decrypt on the recipient’s device
Only a device that holds the necessary decryption key can return data to plaintext. In true E2EE, intermediaries never receive or store those keys in a form that allows decryption.

Symmetric vs. asymmetric encryption (and why backups use both)

Symmetric encryption uses the same key to encrypt and decrypt. It’s fast and ideal for large files and many small objects. The challenge is secure key distribution.
Asymmetric (public‑key) encryption uses a key pair: a public key for encryption and a private key for decryption. It solves the distribution problem but is slower for bulk data.

Backup systems typically use a hybrid model:

Encrypt data with a symmetric key for performance.
Encrypt (“wrap”) that symmetric key with the user’s public key, or derive keys from a user‑controlled secret (e.g., passphrase) using a strong KDF (scrypt/Argon2/PBKDF2).
Store only the wrapped keys and ciphertext. Without the private key (or passphrase‑derived key material), decryption is not possible.

What end-to-end encryption looks like in backup architectures

Endpoint‑first encryption: Files are encrypted on laptops/desktops/servers before they leave the device. Intermediary services handle storage and orchestration but never see plaintext.
Key management models:
- Provider‑managed keys (server‑side encryption): simpler operations, but not E2EE because the provider can decrypt.
- Customer‑managed keys / private key mode: the provider never has the keys needed to decrypt. Recovery is only possible for those who hold the keys.
- Operational safeguards: keys should be protected at rest with hardware security modules (HSMs) or platform key stores when present, and never transmitted in plaintext.
Restore flow: To recover data, a user or authorized admin presents the key material (e.g., private key or passphrase) locally. The service returns encrypted data; decryption occurs on the endpoint.
Metadata considerations: E2EE protects content. Depending on implementation, some metadata (e.g., account identifiers, object sizes/timestamps) may remain visible to the service for billing and operations. Designs vary on whether filenames and directory structures are encrypted.

Practical use cases for end-to-end encryption in backup

Cloud backups of business‑critical data: Encrypt on the device, store ciphertext in the cloud. This mitigates risks from storage compromise or insider access in multi‑tenant environments.
Complete device backups (files/folders/settings): E2EE protects data during continuous, incremental backups and across restores—from single‑file recovery to full endpoint rebuilds.
Remote/BYOD and unmanaged devices: E2EE reduces privacy concerns for distributed teams because the service cannot read user content. Keys remain under user/org control.
Multi‑destination / multi‑region strategies: Combine symmetric encryption for performance with public‑key wrapping for secure key exchange so encrypted data can safely replicate across regions/providers.
Long‑term retention with confidentiality: Maintain E2EE across the data lifecycle so archives remain protected from future threats and insider access. Pair with versioning and retention policies for compliance use cases.

Note on SaaS platforms: Many file storage/collaboration services (e.g., standard configurations of common cloud drives) use provider‑managed keys. That is not E2EE. Dedicated SaaS‑backup tools may offer customer‑managed keys to achieve an E2EE posture.

Benefits (and what they depend on)

Confidentiality: Only authorized endpoints can decrypt. Theft of stored ciphertext or interception in transit yields unusable data without keys.
Integrity: Authenticated encryption and/or signatures make tampering evident. Even minimal changes can invalidate a backup object.
Reduced third‑party exposure: Providers, ISPs, and network observers cannot read content; this materially limits insider and bulk‑surveillance risk.
User trust: Teams can collaborate and restore with confidence knowing content remains private to the organization.
Regulatory alignment: Strong encryption supports privacy‑by‑design programs and may qualify data for certain breach‑notification safe harbors when keys are not compromised (jurisdiction‑specific; consult counsel).

Trade‑offs and responsibilities

Key loss = data loss: In customer‑managed key models, losing keys or passphrases can make recovery impossible. Plan for secure escrow (e.g., split knowledge, secret sharing, or enterprise key escrow) and well‑documented break‑glass procedures.
eDiscovery and DLP: Because providers cannot read content, scanning/classification must occur on endpoints or after decryption within your environment. Align legal hold and retention with how and where decryption can lawfully occur.
Performance and UX: E2EE adds local crypto work. Use chunking, deduplication, and incremental strategies to keep backup windows and restores painless.
Metadata exposure: Some operational metadata is often visible to the service. Understand what’s protected vs. what’s observable.

Common misconceptions

“TLS alone gives me E2EE.” TLS protects the connection; true E2EE protects the payload so only endpoints can decrypt.
“If the provider encrypts at rest, it’s E2EE.” Not if the provider controls the keys.

What are immutable backups?

September 8, 2025

What is file versioning?

August 13, 2025

What is Gmail Backup?

August 12, 2025

What is GDPR Compliance?

July 28, 2025

CrashPlan provides cyber-ready data resilience and governance in a single platform for organizations whose ideas power their revenue. With its comprehensive backup and recovery capabilities for data stored on servers, on endpoint devices, and in SaaS applications, CrashPlan’s solutions are trusted by entrepreneurs, professionals, and businesses of all sizes worldwide. From ransomware recovery and breaches to migrations and legal holds, CrashPlan’s suite of products ensures the safety and compliance of your data without disruption.