Identity Key (IK_a)
  ├─ Long-term key (never changes)
  ├─ Curve25519 private/public
  └─ Used to verify Alice's identity

Ephemeral Key (EK_a)
  ├─ One-time key (changes per session)
  ├─ Generated fresh for initial contact
  └─ Used only for first message

Prekeys (PK_a)
  ├─ 100 keys uploaded to server
  ├─ Used by Bob to initiate (no prior contact)
  └─ Signed by Identity Key for verification

Alice → Server:
  1. Sends IK_a (identity key)
  2. Generates 100 Prekeys
  3. Uploads (Prekeys + IK_signature)

Bob ← Server (wants to message Alice):
  1. Requests one of Alice's Prekeys
  2. Server returns: { prekey, signature, IK_a }
  3. Bob verifies signature with IK_a

Bob → Alice (Initial Message):
  DH1 = ECDH(IK_b, EK_a)        # Bob identity ← → Alice ephemeral
  DH2 = ECDH(EK_b, IK_a)        # Bob ephemeral ← → Alice identity
  DH3 = ECDH(EK_b, EK_a)        # Bob ephemeral ← → Alice ephemeral
  DH4 = ECDH(IK_b, PK_a)        # Bob identity ← → Alice prekey

  Shared_Secret = KDF(DH1 || DH2 || DH3 || DH4)
  
  ├─ First root_key = KDF(Shared_Secret, "root")
  ├─ First send_chain_key = KDF(Shared_Secret, "chain")
  └─ Encryption_key = HKDF(chain_key)

First message encrypted with Encryption_key
  └─ Only Alice can decrypt (knows her prekey)

Alice receives, decrypts:
  ├─ Recovers Shared_Secret (same DH4 with her PK_a)
  ├─ Derives first receive_chain_key
  └─ Decrypts message + continues conversation

Alice sends message to Bob:

1. Current Chain Key: chain_key = HKDF(root_key, 32 bytes)
2. Message Key: msg_key = HKDF(chain_key, 32 bytes)
3. Nonce: nonce = message_counter (strictly increasing)

4. AEAD Encryption:
   ciphertext = ChaCha20Poly1305::encrypt(
     key: msg_key,
     nonce: nonce,
     plaintext: message,
     ad: sender_id || recipient_id || msg_num
   )

5. Ratchet Forward:
   new_chain_key = HKDF(chain_key, 32 bytes)
   root_key_new = HKDF(root_key, 32 bytes)  # Every 100 messages

6. Generate New Ephemeral:
   new_ephemeral_key = X25519::generate()
   new_root_key = ECDH(new_ephemeral, bob_ephemeral)

7. Wrap in Protocol Message:
   {
     "type": "message",
     "sender_id": alice_id,
     "dh_public": alice_ephemeral.public,
     "chain_num": current_chain_number,
     "msg_num": message_counter,
     "ciphertext": base64(ciphertext),
     "auth_tag": base64(poly1305_tag)
   }

8. Server Relay (if Bob offline):
   - Server stores encrypted blob
   - Stores: (to_phone_hash, from_phone_hash, blob, ttl=7d)
   - Does NOT decrypt, does NOT log content

Bob receives message:

1. Extract DH Public (alice_ephemeral)
2. Perform DH Ratchet:
   shared_secret = ECDH(bob_ephemeral_private, alice_ephemeral)
   
3. Update Root Key:
   new_root_key = HKDF(root_key, shared_secret)
   
4. Advance Chain Key:
   for i in range(msg_num - current_msg_num):
     chain_key = HKDF(chain_key)
   
5. Derive Message Key:
   msg_key = HKDF(chain_key)
   
6. Verify & Decrypt:
   plaintext = ChaCha20Poly1305::decrypt(
     key: msg_key,
     nonce: msg_num,
     ciphertext: ciphertext,
     ad: sender_id || recipient_id || msg_num,
     auth_tag: auth_tag
   )
   
   ├─ If auth_tag fails → ABORT (tampering detected)
   └─ If success → Plaintext ✓
   
7. Update Ephemeral:
   bob_ephemeral = alice_ephemeral (for next message from Alice)
   
8. Ratchet Bob's Send Chain (for reply):
   bob_new_ephemeral = X25519::generate()
   bob_root_key = ECDH(bob_new_ephemeral, alice_ephemeral)

✓ Perfect Forward Secrecy: Old messages can't be decrypted 
  even if long-term keys compromised

Threat: Attacker intercepts network traffic
Mitigation:
  ├─ TLS 1.3: All client↔server communication encrypted
  ├─ Noise E2E: End-to-end encryption (even server can't read)
  ├─ Perfect Forward Secrecy: Old messages safe even if keys stolen
  └─ Authentication: AEAD prevents tampering

Result: ✓ Confidentiality guaranteed

Threat: Attacker intercepts and modifies messages
Mitigation:
  ├─ Poly1305 Authentication Tag: Detects tampering
  ├─ Key Fingerprints: Users verify each other's identity
  ├─ Proof of Work: SMS verification prevents fake accounts
  └─ Signature Verification: Prekeys signed with Identity Key

Result: ✓ Integrity guaranteed

Scenario 1: Long-term Identity Key stolen
Threat: Attacker can impersonate user in future
Mitigation:
  ├─ Device compromise detection: key change alert
  ├─ Multiple devices: other devices unaffected
  └─ Manual key rotation available

Result: ⚠ Partial (need key rotation mechanism)

Scenario 2: Session Key stolen (ephemeral)
Threat: Attacker can read current session
Mitigation:
  ├─ Double Ratchet: Key changes every message
  ├─ Forward Secrecy: Can't read past messages
  └─ Receive Ratchet: Can't read future messages

Result: ✓ Only current message readable (limited damage)

Threat: Attacker gains access to server
Attacker can see:
  ├─ Phone number → Public Key mapping
  ├─ Group metadata (names, member list - encrypted)
  ├─ Encrypted message blobs (can't decrypt)
  ├─ Presence status (online/offline)
  └─ Timestamps (not meaningful without content)

Attacker CANNOT see:
  ├─ Message content (Noise E2E encrypted)
  ├─ File contents (encrypted before upload)
  ├─ Voice/video (WebRTC encrypted)
  ├─ Contact list (stored only on device)
  └─ Long-term keys (never sent to server)

Result: ✓ Content safe, metadata leaks only

Mitigation:
  ├─ Regular backups
  ├─ Monitoring/alerting
  ├─ Encrypted database backups
  ├─ Regular security audits
  └─ Open-source code (anyone can audit)

What they can see:
  ├─ You connected to messenger.example.com
  ├─ Traffic volume (how much data)
  ├─ Frequency of messages (timing correlation)
  ├─ IP addresses of communication parties
  └─ DNS queries

What they CANNOT see:
  ├─ Message content (E2E encrypted)
  ├─ Who you're talking to (if using Tor/VPN)
  ├─ File contents
  └─ Metadata (if properly stripped)

Mitigation (User's responsibility):
  ├─ Use VPN/Tor for IP anonymity
  ├─ Avoid patterns (don't message at predictable times)
  └─ Disable traffic analysis

iOS:
  ├─ Identity Keys: Stored in Secure Enclave
  │  └─ Encrypted, hardware-backed, can't export
  ├─ Session Keys: Stored in Keychain
  │  └─ Protected with device passcode
  └─ Database: Encrypted with SQLCipher (AES-256)

Android:
  ├─ Identity Keys: Stored in AndroidKeyStore
  │  └─ Hardware-backed if available, SW fallback
  ├─ Session Keys: Stored in EncryptedSharedPreferences
  │  └─ AES-256 by default
  └─ Database: Encrypted with SQLCipher (AES-256)

Local Attacker (physical device access):
  ├─ If device unlocked: Can access all data
  │  └─ Mitigation: Use strong passcode + biometric
  ├─ If device locked: Secure Enclave/Keystore protects keys
  └─ Without passcode: Forensic extraction possible
     └─ Mitigation: Factory reset or key rotation

Remote Attacker (compromised app):
  ├─ Can access decrypted data in memory
  ├─ Can intercept new messages
  └─ Mitigation: Code review + reproducible builds

Malicious OS:
  ├─ Can theoretically intercept anything
  └─ Mitigation: Keep OS updated + careful app permissions

1. Generation
   ├─ On-device only
   ├─ Using OS's secure random
   └─ Keys never leave device at creation

2. Upload (Public Keys Only)
   ├─ Identity Public Key → Server (on registration)
   ├─ Prekeys → Server (100 at a time)
   ├─ Signed with Identity Private Key
   └─ Verification by recipients

3. Storage
   ├─ Private Keys: Never leave device
   ├─ Session Keys: Encrypted local storage
   └─ Backups: Optional encrypted cloud backup (user choice)

4. Usage
   ├─ Ephemeral keys: Generated per-session, deleted after use
   ├─ Chain keys: Ratcheted forward every message
   └─ Message keys: Used once, discarded

5. Rotation
   ├─ Automatic: Ephemeral keys (every message)
   ├─ Periodic: Session keys (every 100 messages)
   ├─ Manual: Identity keys (user-initiated)
   └─ Revocation: Lost device (mark old keys untrusted)

6. Deletion
   ├─ Explicit: User deletes contact
   ├─ Automatic: Archived after 30 days inactivity
   └─ Secure Erase: Use TRIM command (SSDs)

User A wants to verify User B:

1. Both users see 256-bit fingerprints:
   FP_B = BLAKE2b(identity_public_key_b, 32 bytes)
   Display as: 4FD7-8E2A-91C3-45B6-...
   
2. Verify through trusted channel:
   ├─ In-person meeting
   ├─ Phone call
   ├─ Video call
   └─ Other messaging app
   
3. If match: Mark as "Trusted"
   ├─ Future messages have ✓ badge
   ├─ Warning if key changes
   └─ Require re-verification for new device

4. If mismatch: Possible MITM!
   ├─ DO NOT continue conversation
   ├─ Contact user through other channel
   └─ Investigate compromise

Alice sends first message:

1. Generate ephemeral key: ek_a
2. Compute commitment: H(ek_a) = BLAKE2b(ek_a)
3. Send in plaintext (commitment)

4. Send in ciphertext (ephemeral key)
   └─ Only after verifying receipt

5. Bob verifies:
   ├─ Decrypts ciphertext → ek_a'
   ├─ Computes H(ek_a')
   └─ Compares with commitment
   
Result: Commitment binding ensures key can't be changed