intermediate9 min readUpdated 2026-06-08

Encryption: TLS, AES, Key Management and Data Protection

Learn encryption for system design: TLS in transit, AES at rest, end-to-end encryption, key rotation, KMS, certificate management, and tradeoffs.

Quick answer: Encryption: TLS, AES, Key Management and Data Protection

Encryption: TLS, AES, Key Management and Data Protection is covered here as a practical system design concept. Learn encryption for system design: TLS in transit, AES at rest, end-to-end encryption, key rotation, KMS, certificate management, and tradeoffs. Use it to understand the Networking idea, where it appears in production systems, and how to discuss it clearly in interviews.

Focus on the problem being solved, the main design choice, the failure mode, and the tradeoff you would defend in front of a senior engineer. This page is part of the DosiBridge system design knowledge graph, so it links related concepts, interview problems, tradeoffs, and references instead of leaving the topic isolated.

Aspect	Details
What it is	Transforming data into an unreadable format using cryptographic algorithms and keys, ensuring only authorized parties can access the original data
When to use	Always — every production system should encrypt data in transit (TLS) and sensitive data at rest (AES-256). E2E for messaging, healthcare, finance
When NOT to use	Public, non-sensitive data that is already freely available — encryption adds latency and CPU cost without benefit if the data is not confidential
Real-world example	WhatsApp uses end-to-end encryption for 100 billion messages per day — even WhatsApp servers cannot read message content
Interview tip	Distinguish symmetric (AES, same key) from asymmetric (RSA/ECDSA, key pairs) and know when each is used (TLS handshake uses both)
Common mistake	Rolling your own cryptography instead of using proven libraries — custom crypto is almost always broken. Use libsodium, OpenSSL, or platform-provided APIs
Key tradeoff	Security vs performance — encryption adds CPU overhead (1-5% for TLS, more for at-rest encryption) and complexity (key management, rotation)

Why This Matters

Data breaches cost companies an average of $4.45 million (IBM 2023 report). Encryption is the primary defense. Encryption in transit (TLS) prevents eavesdropping on network traffic. Encryption at rest protects data if storage is compromised (stolen disks, backup leaks). End-to-end encryption ensures that even the service provider cannot read user data. Compliance regulations (GDPR, HIPAA, PCI-DSS) mandate encryption. In system design interviews, any discussion of sensitive data (passwords, payments, health records) requires demonstrating understanding of encryption at multiple layers.

System architecture diagram for Encryption showing how services, databases, and caches connect — System architecture for Encryption

The Building Blocks

Symmetric Encryption (AES): Same key for encryption and decryption. AES-256 is the standard. Fast (hardware-accelerated on modern CPUs). Used for bulk data encryption at rest and in E2E payloads.
Asymmetric Encryption (RSA/ECDSA): Public key encrypts, private key decrypts (or signs). Slower than symmetric. Used for key exchange in TLS handshake and digital signatures for authentication.
TLS (Transport Layer Security): Encrypts all data in transit between client and server. TLS 1.3 reduces handshake to 1 round-trip. Uses asymmetric crypto for key exchange, then symmetric for data.
Key Management: Secure generation, storage, rotation, and revocation of encryption keys. Use AWS KMS, Azure Key Vault, or HashiCorp Vault. Never store keys alongside encrypted data.
End-to-End Encryption: Only sender and receiver hold decryption keys. The server relays ciphertext without ability to read it. Signal Protocol (used by WhatsApp) is the standard implementation.

Under the Hood

TLS establishes an encrypted channel in three steps: the client sends a ClientHello with supported cipher suites, the server responds with its certificate and chosen cipher, and they perform a key exchange (ECDHE in TLS 1.3) to derive a shared symmetric key. All subsequent data is encrypted with AES-256-GCM using this key. TLS 1.3 completes this in a single round-trip (1-RTT), or even zero round-trips for resumed sessions (0-RTT).

Step-by-step diagram showing how Encryption processes a request from start to finish — How Encryption works step by step

For encryption at rest, the standard approach is envelope encryption: a data encryption key (DEK) encrypts the data, and a key encryption key (KEK) stored in a KMS encrypts the DEK. The encrypted DEK is stored alongside the data. To decrypt, the application calls the KMS to decrypt the DEK, then uses the DEK to decrypt the data. This design means the KMS never sees the actual data, and rotating the KEK does not require re-encrypting all data.

End-to-end encryption adds another layer: each user has a key pair (public and private). Alice encrypts a message with Bob's public key; only Bob's private key can decrypt it. The server stores only ciphertext. The Signal Protocol extends this with forward secrecy: each message uses a new ephemeral key, so compromising one key does not compromise past messages. This is how WhatsApp encrypts 100 billion messages per day.

How Companies Actually Do This

WhatsApp encrypts 100 billion messages daily using the Signal Protocol. Even Meta servers cannot read message content. Each conversation uses a unique session key with forward secrecy.

Comparison table for Encryption contrasting approaches, tradeoffs, and when to use each — Comparing key aspects of Encryption

AWS provides KMS (Key Management Service) for envelope encryption. S3 server-side encryption, RDS encryption at rest, and EBS volume encryption all use KMS-managed keys.

Google encrypts all data at rest by default across all Google Cloud services. They use a multi-layer key hierarchy with hardware security modules (HSMs) at the root of trust.

Common Pitfalls

Storing encryption keys alongside encrypted data — if an attacker gets the database, they get the keys too. Use a dedicated KMS (AWS KMS, Azure Key Vault)
Implementing custom cryptographic algorithms — virtually all homegrown crypto has vulnerabilities. Use proven libraries: libsodium, OpenSSL, or platform APIs
Not rotating encryption keys — compromised keys remain dangerous indefinitely. Automate key rotation with envelope encryption so re-encrypting data is just re-wrapping the DEK

Data flow diagram for Encryption showing how requests and responses move through the system — Data flow through Encryption

Interview Questions Worth Practicing

How does TLS establish an encrypted connection, and what changed in TLS 1.3?
What is envelope encryption, and why is it used for data at rest?
How does end-to-end encryption differ from transport encryption, and when is each sufficient?

The Tradeoffs

Security vs Performance: Encryption adds CPU overhead (1-5% for TLS, more for at-rest) and latency (TLS handshake adds a round-trip). Modern hardware acceleration (AES-NI) minimizes this.
E2E Privacy vs Server Functionality: End-to-end encryption means the server cannot read data, which prevents server-side search, spam filtering, and content moderation.
Key Complexity vs Protection: Stronger key management (HSMs, automatic rotation, envelope encryption) provides better security but adds operational complexity and dependency on KMS availability.

Component diagram for Encryption showing each building block and its responsibility — Key components of Encryption

How to Explain This in an Interview

Here is how I would explain Encryption in a system design interview:

Encryption protects data at three layers. In transit: TLS encrypts all network communication — the client and server perform a key exchange (ECDHE in TLS 1.3) and derive a shared AES-256 key for the session. At rest: I use envelope encryption — a data key encrypts the data, and a KMS-managed key encrypts the data key. This way, key rotation does not require re-encrypting all data. End-to-end: for messaging or health data, only the sender and receiver hold keys. The server stores ciphertext it cannot read. The critical rule is never implement custom crypto — use proven libraries and managed services (AWS KMS, Azure Key Vault). In a system design, I always specify which layer handles encryption and where keys are stored.

Interview preparation checklist for Encryption with key points to mention and mistakes to avoid — Interview tips for Encryption

Original DosiBridge notes for Encryption: TLS, AES, Key Management and Data Protection

This section is written specifically for this page, not copied from a general system-design checklist. The useful way to study Encryption: TLS, AES, Key Management and Data Protection is to connect the concept to a trust boundary where convenience must not weaken identity, confidentiality, or auditability. That framing changes the design discussion from definitions to operating choices.

What makes this topic distinct

Packet Path: For Encryption: TLS, AES, Key Management and Data Protection, decide the packet path before choosing tools; otherwise the design looks clean but fails when encryption changes.
Timeout Budget: For Encryption: TLS, AES, Key Management and Data Protection, decide the timeout budget before choosing tools; otherwise the design looks clean but fails when encryption changes.
TLS Boundary: For Encryption: TLS, AES, Key Management and Data Protection, decide the TLS boundary before choosing tools; otherwise the design looks clean but fails when encryption changes.
Proxy Behavior: For Encryption: TLS, AES, Key Management and Data Protection, decide the proxy behavior before choosing tools; otherwise the design looks clean but fails when encryption changes.
Backpressure: For Encryption: TLS, AES, Key Management and Data Protection, decide the backpressure before choosing tools; otherwise the design looks clean but fails when encryption changes.

Production review question

If a team adopts Encryption: TLS, AES, Key Management and Data Protection, what observable signal proves it helped instead of only making the architecture diagram more fashionable?

Practical metric to track

Track encryption health as a named dashboard or review item: combine one user-facing metric, one saturation metric, and one correctness metric. For Encryption: TLS, AES, Key Management and Data Protection, this keeps the discussion grounded in behavior that can be measured after deployment instead of generic advice that sounds good in an interview but never gets verified.