End-to-end encryption concept in HLD - System Design Exercise

Design: End-to-End Encryption Messaging System

Design focuses on encryption architecture, key management, message flow, and storage. UI/UX and network transport protocols are out of scope.

Functional Requirements

FR1: Messages must be encrypted on the sender's device and decrypted only on the receiver's device.

FR2: No intermediate server or third party can read the message content.

FR3: Support secure key exchange between users.

FR4: Allow sending text messages and attachments securely.

FR5: Ensure message integrity and authenticity.

FR6: Support offline message delivery with encrypted storage on server.

FR7: Handle multiple users and group chats securely.

Non-Functional Requirements

NFR1: System should support 1 million daily active users.

NFR2: Message delivery latency p99 should be under 500ms.

NFR3: Availability target is 99.9% uptime.

NFR4: Encryption and decryption must happen on client devices only.

NFR5: Server must not store any plaintext messages or encryption keys.

Think Before You Design

Questions to Ask

❓ Question 1

❓ Question 2

❓ Question 3

❓ Question 4

❓ Question 5

❓ Question 6

Key Components

Client encryption module

Key exchange service

Message relay server

Encrypted message storage

User identity and authentication service

Push notification service

Design Patterns

Public key cryptography for key exchange

Symmetric encryption for message content

Double ratchet algorithm for forward secrecy

Digital signatures for message authenticity

End-to-end encrypted group messaging protocols

Reference Architecture

  +-------------+       +----------------+       +-------------+
  |  Sender's   | <---> | Message Relay  | <---> | Receiver's  |
  |  Device     |       | Server         |       | Device      |
  +-------------+       +----------------+       +-------------+
        |                      |                       |
        | Encrypt message      |                       |
        | with receiver's      |                       |
        | public key           |                       |
        |--------------------->|                       |
        |                      | Store encrypted       |
        |                      | message if receiver   |
        |                      | offline               |
        |                      |----------------------->|
        |                      |                       | Decrypt message
        |                      |                       | with private key
        |                      |                       |
  +----------------+       +----------------+       +----------------+
  | Key Exchange   |       | Encrypted Msg  |       | Decryption &   |
  | Service        |       | Storage        |       | Verification   |
  +----------------+       +----------------+       +----------------+

Components

Client Encryption Module

Implemented in client apps (mobile, desktop)

Encrypts outgoing messages and decrypts incoming messages using user's private keys

Key Exchange Service

Public key infrastructure (PKI) with secure key distribution

Facilitates secure exchange of public keys and session keys between users

Message Relay Server

Stateless message broker with encrypted message storage

Relays encrypted messages between users and stores messages temporarily if receiver is offline

Encrypted Message Storage

Encrypted database or object storage

Stores encrypted messages without access to plaintext or keys

User Identity and Authentication Service

OAuth 2.0 or similar authentication system

Authenticates users and manages user identities securely

Push Notification Service

Platform-specific push services (APNs, FCM)

Notifies users of new messages without revealing message content

Request Flow

1. 1. Sender's device generates a session key for symmetric encryption.

2. 2. Sender encrypts the message content with the session key.

3. 3. Sender encrypts the session key with receiver's public key.

4. 4. Sender sends the encrypted session key and encrypted message to the Message Relay Server.

5. 5. Message Relay Server stores the encrypted message if receiver is offline or forwards it immediately.

6. 6. Receiver's device receives the encrypted session key and message.

7. 7. Receiver decrypts the session key with their private key.

8. 8. Receiver decrypts the message content with the session key.

9. 9. Receiver verifies message authenticity using digital signatures.

10. 10. For group chats, the process repeats with keys managed per participant using group encryption protocols.

Database Schema

Entities: - User: user_id (PK), public_key, authentication_info - Message: message_id (PK), sender_id (FK), receiver_id (FK), encrypted_session_key, encrypted_content, timestamp, signature - Group: group_id (PK), group_name - GroupMember: group_id (FK), user_id (FK), encrypted_group_key Relationships: - User to Message: 1-to-many (sender and receiver) - Group to GroupMember: 1-to-many - User to GroupMember: many-to-many Notes: - No plaintext message content stored. - Keys stored only in encrypted form or on client devices.

Scaling Discussion

Bottlenecks

Key exchange service can become a bottleneck with many users requesting keys simultaneously.

Message Relay Server may face high load during peak messaging times.

Encrypted message storage can grow rapidly with large user base.

Latency may increase if many users are offline and messages are queued.

Group chat key management complexity grows with group size.

Solutions

Use distributed key exchange servers with caching of public keys to reduce load.

Scale message relay servers horizontally with load balancers.

Implement data retention policies and archiving for encrypted messages.

Use efficient push notification to wake offline users quickly.

Adopt advanced group encryption protocols like Sender Keys to reduce key management overhead.

Interview Tips

Time: Spend 10 minutes clarifying requirements and constraints, 20 minutes designing architecture and data flow, 10 minutes discussing scaling and trade-offs, 5 minutes summarizing.

Explain why encryption must happen on client devices only.

Describe how public key cryptography enables secure key exchange.

Discuss how message integrity and authenticity are ensured.

Highlight how offline message delivery is handled securely.

Mention trade-offs between security and usability (e.g., key recovery).

Show awareness of scaling challenges and practical solutions.