WhatsApp Security

A brief overview of the encryption systems for whatsapp

Introduction

• The Signal Protocol, designed by Open Whisper Systems, is the basis for WhatsApp’s end-to-end encryption

• Due to the ephemeral nature of the cryptographic keys, even in a situation where the current encryption keys from a user’s device are physically compromised, they cannot be used to decrypt previously transmitted messages.

• A user can have multiple devices, each with its own set of encryption keys. If the encryption keys of one device are compromised, an attacker cannot use them to decrypt the messages sent to other devices, even devices registered to the same user.

⚠️This blog gives an overview of the Signal Protocol and its use in WhatsApp in the context of establishing sessions and sending and receiving different kinds of messages

Terms

Devices

• Primary device (your phone) - device that user registered whatsapp in (every user has exactly one primary device)

• Companion device (your laptop) - device that is linked to whatsapp account by primary

• Cloud API - Meta’s own API service check it out at

Overview - Cloud API - Documentation - Meta for Developers

Public Key types

• Identity key pair - A long-term Curve25519 key pair, generated at install time.

  • Purpose: This key pair is used to identify the user.

  • Duration: It’s called long-term because it sticks around for a long time, usually until you reinstall WhatsApp or change devices.

  • Use Case: Think of it as your permanent ID card. It's primarily used for authenticating your identity when setting up secure communication channels.

  • Security: It's never shared directly with anyone. Instead, your public key is used in creating secure, encrypted channels for chats.

• Signed Pre-key

  • Purpose: This key pair acts like a temporary helper to kickstart the secure session.

  • Duration: It's called medium-term because it changes more frequently than the long-term key but isn’t used for just a single session. WhatsApp updates it periodically (like every few weeks or when it gets used).

  • Use Case: Imagine it like a temporary access badge. It helps speed up the initial secure message exchange between two users, making sure the chat starts off securely even before they’ve had a chance to exchange messages directly.

  • Security: The public part of this medium-term key is shared with the WhatsApp server so other users can grab it to start a conversation with you. But the private part stays on your device.

• One-time Pre-key

  • One-time pre-keys are temporary Curve25519 key pairs that are used only once to establish a secure session.

  • These keys are like single-use codes or one-time tickets at a concert—once they’re used, they’re discarded and never reuses

Session Key Types

• Root Key – A 32-byte value that is used to create Chain Keys.

• Chain Key – A 32-byte value that is used to create Message Keys.

• Message Key – An 80-byte value that is used to encrypt message contents.

  • 32 bytes are used for an AES-256 key,

  • 32 bytes for a HMAC-SHA256 key, and

  • 16 bytes for an IV

What is HMAC-SHA256?

HMAC-SHA256 stands for Hash-based Message Authentication Code using the SHA-256 hashing algorithm. Let’s break it down:

1. HMAC (Hash-based Message Authentication Code):

   • It’s a security mechanism used to check the integrity and authenticity of a message.

   • It helps make sure that:

     • The message hasn’t been tampered with (integrity).

     • The message really came from the intended sender (authenticity).

2. SHA-256 (Secure Hash Algorithm 256-bit):

   • This is the specific hash function used in HMAC.

   • It takes an input (like a message) and produces a fixed-size 256-bit (32-byte) hash value, often called a digest.

   • SHA-256 is part of the SHA-2 family of cryptographic hash functions and is known for being very secure.

How Does HMAC-SHA256 Work? 🔧

HMAC-SHA256 combines a secret key and the message content using the SHA-256 hashing algorithm. Here’s a simple step-by-step of what happens:

1. Input:

   • You have a message (the content you want to send).

   • You have a secret key (only known to the sender and receiver).

2. Hashing:

   • The HMAC process mixes the message and the secret key together in a specific way.

   • It then uses the SHA-256 algorithm to generate a fixed-size digest (like a fingerprint) of the mixed input.

3. Output:

   • The result is a HMAC-SHA256 digest. This is a 256-bit (32-byte) value that acts like a signature for the message.

Why HMAC-SHA256 is Used in WhatsApp

In WhatsApp’s encryption system, HMAC-SHA256 helps to:

1. Verify Message Integrity:

   • When you send a message, the HMAC-SHA256 digest is generated using the message content and a HMAC key (part of the 80-byte message key).

   • The receiver computes the HMAC digest again using the same secret key and compares it with the received digest. If they match, it means the message hasn’t been tampered with.

2. Authenticate the Sender:

   • Since the HMAC key is secret and only known to the sender and receiver, it proves that the message came from the expected sender and not someone else.

Example in Action

Let’s say Alice sends a message "Hi, Bob!" to Bob:

1. WhatsApp generates an HMAC-SHA256 digest for "Hi, Bob!" using a secret HMAC key (key2 from the message key).

2. The message "Hi, Bob!" and its HMAC digest are sent to Bob.

3. When Bob receives the message, he uses the same HMAC key to generate a new HMAC digest for "Hi, Bob!".

4. Bob compares his HMAC digest with the one he received:

   • If they match, the message is authentic and hasn’t been changed.

   • If they don’t match, it means the message was tampered with, and Bob knows something is wrong.

Why It’s Important

HMAC-SHA256 makes sure that any changes to the message during transmission (like someone trying to alter it) will be detected. It’s like putting a tamper-proof seal on your message to ensure it hasn’t been messed with. 🔒💬✅

In short, HMAC-SHA256 adds an extra layer of security, ensuring your messages aren’t altered or forged while being sent over WhatsApp. 💥🔐

What is IV (Initialization Vector)? 🤔

• The Initialization Vector (IV) is a crucial part of the message key in encryption. Here's why it matters:

  • The IV is like a random starting point that gets mixed in with the message data before encryption begins.

  • It ensures that even if you send the same message twice, the encrypted output will be different each time.

  • This prevents attackers from spotting patterns or guessing message content based on repeated encrypted outputs.

  Example of How IV Works

  Imagine you want to send the message "Hello" twice:

  1. Without an IV:

     • If you encrypt "Hello" both times with the same key, the encrypted output (ciphertext) would be the same: ENCRYPT("Hello", key) -> "abc123".

     • An attacker could notice this repetition and start guessing or making assumptions about your messages.

  2. With an IV:

     • For the first message: ENCRYPT("Hello", key, IV1) -> "xyz456".

     • For the second message: ENCRYPT("Hello", key, IV2) -> "def789".

     • Even though the same message was sent, the ciphertext looks different because the IV was different each time.

Other key types

• Linking Secret Key -

  • A 32-byte value that is generated on a companion device

  • must be passed by a secure channel to the primary device,

  • used to verify an HMAC of the linking payload received from a primary device.

  • The transmission of this key from companion devices to the primary device is done by scanning a QR code.

Companion Linking in WhatsApp

When you link a companion device (like a secondary phone or WhatsApp Web) to your primary WhatsApp account, several security checks and signatures ensure the link is secure.

1. Linking Metadata:

   • An encoded blob of data assigned to the companion device during linking.

   • It works with the companion device’s Identity Key to identify and authenticate the linked device on WhatsApp.

2. Signed Device List Data:

   • A list of all currently linked companion devices, signed by the primary device.

   • Uses the 0x0602 prefix and is signed with the primary device’s Identity Key to ensure it hasn’t been tampered with.

3. Account Signature:

   • A Curve25519 signature created by the primary device.

   • It’s computed over:

     • A fixed prefix,

     • The Linking Metadata,

     • The companion device’s public Identity Key.

   • This signature verifies the link between the primary device and the companion device.

4. Device Signature:

   • Another Curve25519 signature, but created by the companion device this time.

   • It’s computed over:

     • A fixed prefix,

     • The Linking Metadata,

     • The companion device’s public Identity Key,

     • The primary device’s public Identity Key.

   • This ensures the companion device can prove its identity and verify the link to the primary device.

Client Registration

Primary Device Registration

• Client sends its public Identity key, public Signed Pre Key (with signature) and a batch of public One-Time Pre Keys to the server which stores there public keys associated user identifier

💡Re-iterating purposes of each key

• Identity key - Used to identify the user

• Signed Pre-key - acts like a temporary helper to kickstart the secure session.

• One-time pre-keys are temporary Curve25519 key pairs that are used only once to establish a secure session

Companion Device Registration

• user’s primary device must first create an account signature by signing the new device’s public Identity Key

• the companion device must create a Device Signature by signing the primary’s public Identity Key

• After this e2e encrypted sessions can be established with the companion device

Linking Using QR Code

💡To make it easy primary client is mobile and secondary client is laptop

• The QR code that you see when you enter web whatsapp has 2 keys

  • The client’s identity key and a generated ephemeral linking secret key

  • The linking secret key is never sent to the server’

• The primary client (most prolly your phone) scans the linking QR code and saves the identity key of the secondary client (laptop) to disk

  • Which is why u can prolly see the list of connected devices and disconnect each one from primary

• The mobile its own Identity Key

• The mobile generates Linking Metadata and updated Device List Data containing the new companion as ListData.

• The mobile generates an Account Signature for the companion

  • ACCOUNT_SIGNATURE_PREFIX = companion == "Cloud API" ? 0x0605 : 0x0600

A_signature = CURVE25519_SIGN(I_primary,ACCOUNT_SIGNATURE_PREFIX || Lmetadata || Icompanion).

• The mobile generates a Device List Signature for the updated Device List Data

ListSignature = CURVE25519_SIGN(I_primary, 0x0602 || ListData)

• Mobile serializes the Linking Data L_Data containing L_metadata , I_primary and A_signature

• Mobile generates a Linking

HMAC , PHMAC  = HMACSHA256(L_companio L_data)

What is PHMAC? 🤔

PHMAC stands for "Pseudo-HMAC", which is a mechanism that WhatsApp uses to create message authentication tags in its encryption protocol. It's part of the process to securely verify message integrity and ensure that the message hasn't been tampered with during transmission.

Why Not Use Standard HMAC Directly? 🤷‍♂️

HMAC is great, but it's also computationally expensive for devices like smartphones that need to process a lot of messages quickly. PHMAC is a lightweight variation designed to speed up operations while still being secure for WhatsApp's use case.

• Mobile sends ListData, ListSignature, L_data and PHMAC to WhatsApp server

• The server stores ListData and ListSignature and forwards L_data and PHMAC to the laptop

• Laptop verifies PHMAC decodes L_data into L_metadata , I_primary and A_signature and verifies A_signature

• Laptop saves L_metadata and I_primary to disk

• Laptop generates a Device Signature for itself

D_signature = CURVE25519_SIGN(I_companion, DEVICE_SIGNATURE_PREFIX
|| L_metadata || I_companion || I_primary)

• DEVICE_SIGNATURE_PREFIX is set to 0x0606 if the companion is Cloud API. Else, it’s set to 0x0601.

• Laptop uploads Lmetadata, Asignature, Dsignature, Icompanion, the companion’s public Signed Pre Key (with its signature), and a batch of public One-Time Pre Keys to WhatsApp server.

• Server stores the uploaded data associated with the user’s identifier combined with a device specific identifier

Linking using 8-character code

Step 1: Generating the Code on the Companion Device

1. User Inputs Their Phone Number:

   • On the companion device, you type in the phone number linked to the WhatsApp account.

   • This lets the companion device know which primary device it’ll try to pair with.

2. Generate a Random Code (Ccompanion):

   • The companion device generates a 40-bit random secret (linkCodePairingSecret) using a secure random number generator (CSPRNG).

   • This secret is converted to an 8-character Base32 alphanumeric code and displayed to you.

3. Generate Random Nonces and IVs:

   • A 32-byte random salt (linkCodePairingKdfCompanionNonce) and a 16-byte random initialization vector (companionHelloIV) are generated.

   • These are used later for encryption and key derivation.

4. Generate Ephemeral Keys for Encryption:

   • The companion creates a curve25519 keypair:

     • linkCodePairingCompanionADVEphemeralPublic: Public key

     • linkCodePairingCompanionADVEphemeralPrivate: Private key

5. Derive an AES256 Key:

   • Using the Ccompanion code and the random salt (linkCodePairingKdfCompanionNonce), the companion derives a 32-byte AES256 encryption key via PBKDF2-HMAC-SHA256.

   • This is called linkCodePairingECDHEncKeyCompanion.

6. Encrypt the Ephemeral Public Key:

   • The companion encrypts its public ephemeral key (linkCodePairingCompanionADVEphemeralPublic) using AES-CTR with the derived AES256 key and IV (companionHelloIV).

7. Prepare the Companion Hello Message:

   • The companion bundles the encrypted ephemeral public key, the salt, and the IV into a message called linkCodePairingWrappedCompanionEphemeralPub.

   • This message is sent to the primary device via WhatsApp servers.

---

Step 2: Receiving the Code on the Primary Device

1. User Inputs the 8-Character Code:

   • You type the code (Ccompanion) displayed on the companion device into your primary device.

2. Unpack the Companion Hello Message:

   • The primary device receives linkCodePairingWrappedCompanionEphemeralPub and extracts:

     • First 32 bytes: linkCodePairingKdfCompanionNonce

     • Next 16 bytes: companionHelloIV

     • Remaining bytes: Encrypted ephemeral public key (linkCodePairingEncryptedCompanionEphemeralPub)

3. Derive the Same AES256 Key:

   • Using the Ccompanion code and the extracted salt, the primary device derives the same AES256 encryption key (linkCodePairingECDHEncKeyCompanion) via PBKDF2-HMAC-SHA256.

4. Decrypt the Companion’s Ephemeral Public Key:

   • The primary device decrypts linkCodePairingEncryptedCompanionEphemeralPub using the derived AES256 key and IV.

   • This gives the companion’s ephemeral public key (linkCodePairingDecryptedCompanionEphemeralPub).

5. Validate the Code:

   • If the entered code (Ccompanion) is incorrect, the decryption produces garbage data.

   • The process aborts here, and you’re prompted to re-enter the code.

Step 3: Sending the Primary Device’s Keys

1. Generate the Primary’s Ephemeral Keys:

   • The primary creates its own curve25519 keypair:

     • linkCodePairingPrimaryADVEphemeralPublic: Public key

     • linkCodePairingPrimaryADVEphemeralPrivate: Private key

2. Derive Another AES256 Key:

   • The primary derives a new AES256 key (linkCodePairingECDHEncKeyPrimary) using the same Ccompanion code but with a new random salt (linkCodePairingKdfPrimaryNonce).

3. Encrypt the Primary’s Ephemeral Public Key:

   • The primary encrypts its public ephemeral key using AES-CTR with the derived key and a new IV (primaryHelloRandomIV).

4. Prepare the Primary Hello Message:

   • The primary bundles its encrypted ephemeral public key, the salt, and the IV into a message (linkCodePairingWrappedPrimaryEphemeralPub) and sends it to the companion device.

Step 4: Key Agreement and Verification

1. Decrypt the Primary’s Ephemeral Public Key:

   • The companion decrypts the primary’s ephemeral public key using the AES256 key derived earlier.

2. Perform ECDH Key Exchange:

   • Both devices now have each other’s decrypted ephemeral public keys.

   • Using their private keys and the other device’s public key, they calculate a shared ECDH secret.

3. Derive a Root Secret:

   • The companion generates a random 32-byte root secret (linkCodePairingEphemeralRootSecret).

4. Create a Key Bundle:

   • The companion constructs a bundle containing:

     • Root secret

     • Companion’s public identity key

     • Primary’s public identity key

5. Encrypt the Key Bundle:

   • The companion derives another AES256 key (linkCodePairingKeyBundleEncryptionKey) from the shared ECDH secret using HKDF.

   • It encrypts the key bundle using AES-GCM and a new random IV.

6. Send the Key Bundle to Primary:

   • The encrypted key bundle, along with its salt and IV, is sent to the primary device.

Step 5: Finalizing the Link

1. Decrypt the Key Bundle:

   • The primary decrypts the key bundle using the same AES256 key derivation process.

2. Verify Key Integrity:

   • The primary verifies the companion’s public identity key and the root secret from the key bundle.

   • If the keys don’t match, the process aborts.

3. Derive the Final Linking Secret Key:

   • Both devices derive the final Linking Secret Key (Lcompanion) from the shared secrets and root secret using HKDF.

4. Establish End-to-End Encryption:

   • Both devices now have Lcompanion and can establish an end-to-end encrypted session.

Initiating session setup

💡WhatsApp uses this “client-fanout” approach for transmitting messages to multiple devices, where the WhatsApp client transmits a single message N number of times to N number of different devices.

Each message is individually encrypted using the established pairwise encryption session with each device.

• The initiating client (initiator) requests the following keys for:

  • Recipient's devices:

    • Public Identity Key (Irecipient): A long-term Curve25519 key.

    • Public Signed Pre Key (Srecipient): A medium-term Curve25519 key signed by the recipient's Identity Key.

    • A single public One-Time Pre Key (Orecipient): A short-lived key used only once.

  • Companion devices (for both accounts):

    • Linking Metadata (Lmetadata): Information about device linkage.

    • Account Signature (Asignature): A signature proving the companion device is authorized by the primary device.

    • Device Signature (Dsignature): A signature proving the companion device's authenticity.

• Server Behavior:

  • The server provides the requested keys.

  • Each One-Time Pre Key is deleted from the server after being used to ensure it’s never reused.

  • If the recipient has run out of One-Time Pre Keys, none will be returned.

• The initiator verifies companion device authenticity using signatures:

  • Account Signature Verification:

    • Validates Asignature using the recipient's primary Identity Key (Iprimary):

CURVE25519_VERIFY_SIGNATURE(Iprimary, 0x0600 || Lmetadata || Icompanion)

• • Device Signature Verification:

    • Validates Dsignature using the companion device's Identity Key (Icompanion):

CURVE25519_VERIFY_SIGNATURE(Icompanion, 0x0601 || Lmetadata || Icompanion || Iprimary)

• If any verification fails, the initiator terminates the session setup for that device and doesn’t send messages to it.

• Once the initiator has verified the keys and signatures for each device, it proceeds to set up encryption sessions:

  1. Save Recipient’s Keys:

     • The initiator saves:

       • Identity Key (Irecipient).

       • Signed Pre Key (Srecipient).

       • One-Time Pre Key (Orecipient) (if available).

  2. Generate an Ephemeral Key Pair:

     • The initiator creates a temporary Curve25519 key pair (Einitiator), unique to this session.

  3. Load Initiator’s Identity Key:

     • The initiator uses its own long-term Identity Key (Iinitiator).

  4. Calculate the Master Secret:

     • The initiator derives a master secret using multiple Elliptic-Curve Diffie-Hellman (ECDH) calculations:

master_secret = ECDH(Iinitiator, Srecipient)
              || ECDH(Einitiator, Irecipient)
              || ECDH(Einitiator, Srecipient)
              || ECDH(Einitiator, Orecipient)

• 1. • If the recipient does not provide a One-Time Pre Key, the final ECDH term is omitted.

  2. Derive Root and Chain Keys:

     • Using the derived master_secret, the initiator applies HKDF (HMAC-based Key Derivation Function) to generate:

       • Root Key: Used to bootstrap the secure session.

       • Chain Keys: Used to derive message encryption keys.

Receiving Session Setup

1. Handling Session Setup Information

The initiator includes the following session setup information in the header of every message sent before the session is established:

• Initiator’s Keys:

  • Ephemeral key pair (Einitiator).

  • Identity Key (Iinitiator).

• Companion Device Information (if the initiator is a companion device):

  • Primary device Identity Key (Iprimary).

  • Linking Metadata (Lmetadata).

  • Account Signature (Asignature).

  • Device Signature (Dsignature).

2. Verifying Companion Device Signatures

If the sender is a companion device, the recipient verifies its authenticity:

• Account Signature Verification:

  • Verifies the Asignature using the primary Identity Key (Iprimary):

CURVE25519_VERIFY_SIGNATURE(Iprimary, 0x0600 || Lmetadata || Icompanion)

• Device Signature Verification:

  • Verifies the Dsignature using the companion device’s Identity Key (Icompanion):

CURVE25519_VERIFY_SIGNATURE(Icompanion, 0x0601 || Lmetadata || Icompanion || Iprimary)

• Failure Handling:

  • If any verification fails, the recipient rejects the message and stops building the encryption session with that device.

3. Calculating the Master Secret

Once the companion device's authenticity is confirmed (if applicable), the recipient calculates the master secret using its own private keys and the public keys provided by the initiator in the message header:

master_secret = ECDH(Irecipient, Einitiator)
              || ECDH(Srecipient, Iinitiator)
              || ECDH(Srecipient, Einitiator)
              || ECDH(Orecipient, Einitiator)

• ECDH Inputs:

  • Irecipient: Recipient’s Identity Key.

  • Srecipient: Recipient’s Signed Pre Key.

  • Orecipient: Recipient’s One-Time Pre Key.

  • Einitiator: Initiator’s Ephemeral Key.

  • Iinitiator: Initiator’s Identity Key.

• If the One-Time Pre Key (Orecipient) is unavailable:

  • The final ECDH term is omitted.

4. Deleting the One-Time Pre Key

After using the One-Time Pre Key (Orecipient) to calculate the master secret, the recipient deletes it to prevent reuse, maintaining forward secrecy.

5. Deriving the Root and Chain Keys

Using the calculated master_secret, the recipient applies the HKDF (HMAC-based Key Derivation Function) to derive:

• Root Key:

  • Acts as a foundation for secure session key management.

• Chain Keys:

  • Used to generate encryption keys for future messages.

Exchanging Messages

• Encryption Tech: Every message uses a unique, temporary "Message Key" derived from a "Chain Key." AES256-CBC encrypts the message, and HMAC-SHA256 ensures authenticity.

• Key Ratchets: The "Chain Key" evolves (or "ratchets") with each message using HMAC-SHA256, ensuring past or future keys can't be derived.

• ECDH Agreements: With every message roundtrip, a fresh key exchange happens, adding an extra layer of forward secrecy.

Media & Attachments

1. Key Generation: For large files (e.g., videos or documents), a 32-byte AES256 key and a 32-byte HMAC-SHA256 key are generated.

2. Encryption: The file is encrypted with the AES256 key. A MAC (message authentication code) ensures integrity.

3. Blob Storage: The encrypted file is uploaded to a server, and a secure message is sent containing:

   • The keys

   • A hash of the file

   • The file's location.

4. Recipient's Role: They download the encrypted file, verify it using the hash and MAC, and decrypt it.

Group Messaging

• Sender Key: Each group has a unique "Sender Key" for encrypting messages. It’s shared with all members individually through pairwise encryption.

• Process:

  1. Sender generates a random "Chain Key" and signature key pair.

  2. Messages are encrypted with AES256-CBC and authenticated with a signature key.

  3. A hash ratchet ensures forward secrecy.

When someone leaves the group, the "Sender Key" is reset.

Add-ons in Announcement Groups

• Key Setup:

  • For reactions and similar add-ons, a unique "Add-on Sender Key" is created.

  • Add-ons are doubly encrypted using:

    1. A derived key from the original message’s "Message Secret."

    2. The "Add-on Sender Key."

Admins reset keys only for regular messages when a member leaves, not for add-ons.

Handling Missed Devices (Sender Side Backfill)

• Device Mismatch: If a sender misses a recipient's devices, the server notifies them to update the list.

• Backfill Process:

  • The sender verifies new devices, establishes encryption sessions, and resends the message.

  • Constraints:

    • Only valid for a short time.

    • Excludes devices that fail verification or have changed identity keys.

Message History Syncing

• Companion Devices:

  • Recent messages are encrypted and sent to newly linked devices.

  • Encrypted data bundles include the sender's identity keys.

  • After syncing, the bundles and keys are deleted.

Call Setup

• One-to-One Calls:

  • Each recipient's device gets a unique SRTP (Secure Real-Time Transport Protocol) master secret.

  • Encryption lasts only for the call's duration.

• Group Calls:

  • Keys reset whenever participants join or leave.

  • The server helps coordinate key distribution but cannot access call content.

Statuses

• Similar to Groups:

  • Statuses use "Sender Keys" for encryption.

  • Key resets occur if privacy settings change (e.g., removing a viewer).

A short note on app state syncing security

This system is designed to ensure that the state of the app, such as chat properties (muted, pinned, etc.) and message-related properties (starred, deleted for me), syncs securely across multiple devices, ensuring a consistent experience without compromising the confidentiality of messages.

Key Concepts:

1. App State:

   • This refers to the settings and data related to chats, messages, and contacts, excluding message content or keys that decrypt messages.

2. Encryption:

   • All data involved in app state syncing is encrypted end-to-end. WhatsApp servers do not have access to the keys used for encryption.

   • Encryption Keys:

     • Various keys are used for different purposes, derived from a Base Key via HKDF (Hash-based Key Derivation Function), including keys for index and value encryption, as well as for snapshot and patch integrity.

3. Collections and Patches:

   • Data changes are grouped into Collections which contain different data types (e.g., chat settings, message states).

   • Changes (Mutations) to these Collections are submitted as Patches, ensuring atomic updates.

   • Patch Queue: This is a server-side list that tracks all recent changes.

   • Snapshots: These are periodic compilations of the app state at a specific time, used for initializing new devices or optimizing data transfers.

Workflow of Encryption and Data Handling:

• Mutations: A client sends changes to the server as Mutations, which are either SET or REMOVE. Each Mutation is encrypted using AES-256 and HMAC-SHA2.

• Base Roller: A server-side process that periodically compiles the changes into Snapshots. This helps manage the data compactly and ensures that all devices can sync efficiently.

• MAC (Message Authentication Code): Used at different stages (index, value, patch) to prevent tampering and ensure data integrity.

Key Security Features:

1. Anti-Tampering:

   • Ensures that Mutations, Patches, and Snapshots cannot be reordered, dropped, or replayed by attackers.

2. Snapshot Integrity:

   • A homomorphic hashing algorithm (LtHash) ensures that any changes to the app state are verifiable and resistant to tampering.

3. Patch Integrity:

   • Each Patch is verified by computing its HMAC over the individual mutations, ensuring its integrity before processing.

Key Rotation and Expiry:

• WhatsApp periodically rotates keys to ensure security.

• Key Rotation:

  • Ensures that if a device is removed or a new key is generated, the encryption keys used by the server and clients are updated accordingly.

  • Post-Rotation Update Obfuscation ensures that the server cannot directly correlate old and new records after key rotation.

  • Asynchronous Key Catch-Up ensures old records are eventually re-encrypted under the new key.

Key Points on Key Management:

• Keys are rotated whenever a device is unregistered, and each device maintains a list of keys with metadata such as KeyID, timestamp, and associated devices.

• Devices perform key rotation through an authenticated pairwise encryption session, ensuring that only authorized devices can receive new keys.

Device and Key Expiry:

• When a device is removed, it submits a Patch marking all previous keys as expired, ensuring that future mutations can only use keys that are still valid.

Conclusion

WhatsApp's security framework combines end-to-end encryption, advanced cryptography, and anti-tampering measures to ensure data privacy and integrity. The introduction of App State Syncing and key rotation practices keeps user data consistent and secure across devices. WhatsApp’s approach sets a strong example of how encryption can protect digital communications while providing a seamless user experience.

Overall the paper helped me get a little bit more comfortable with cryptography and helped me learn a few new terms. Do checkout out the resources tagged if you feel something is missing from the explanation

Resources

• Paper - https://scontent.xx.fbcdn.net/v/t39.8562-6/455962147_1148247109601582_1673264986279156121_n.pdf?_nc_cat=101&ccb=1-7&_nc_sid=e280be&_nc_ohc=O2tQm3WgxAwQ7kNvgGsV9IS&_nc_zt=14&_nc_ht=scontent.xx&_nc_gid=Ajs3MmvFB2FiOgRi21OSSSy&oh=00_AYAnlrpoO6e2H-ONEJ9R10YxrBgVASWsP4pl3Nxxi4nixg&oe=6771D699

• Video covering the basic ideas -

• HMAC - https://medium.com/@short_sparrow/how-hmac-works-step-by-step-explanation-with-examples-f4aff5efb40e