WhatsApp Security

A brief overview of the encryption systems for whatsapp

AKHILESH MANDA
DEC 25, 2024

3 Sha

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 whe
the current encryption keys from a user’s device are physically compromised, th
cannot be used to decrypt previously transmitted messages.
A user can have multiple devices, each with its own set of encryption keys. If th
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 contex
of establishing sessions and sending and receiving different kinds of messages

Terms
Devices
Primary device (your phone) - device that user registered whatsapp in (every use
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

Thanks for reading Project Whitepaper!

Subscribe for free to receive new posts and
support my work.

Type your email... Subscribe

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 chann

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 update
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 know
for being very secure.

How Does HMAC-SHA256 Work? 🔧

HMAC-SHA256 combines a secret key and the message content using the SHA-256 hashin
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 wa

It then uses the SHA-256 algorithm to generate a fixed-size digest (like a fingerprin
of the mixed input.
3. Output:

The result is a HMAC-SHA256 digest. This is a 256-bit (32-byte) value that acts li
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 mess
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 be
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 k
(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 HMA
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 alt
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 bef
encryption begins.

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

This prevents attackers from spotting patterns or guessing message content based o
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 assumpti
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
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 dev

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

Companion Linking in WhatsApp

When you link a companion device (like a secondary phone or WhatsApp Web) to y
primary WhatsApp account, several security checks and signatures ensure the link
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 dev

Uses the 0x0602 prefix and is signed with the primary device’s Identity Ke
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 compan
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
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 pub
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 save
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 containi
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_primar

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 ve
message integrity and ensure that the message hasn't been tampered with during transmissi

Why Not Use Standard HMAC Directly? 🤷‍♂️

HMAC is great, but it's also computationally expensive for devices like smartphones that n
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 PHM
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 AP

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-b

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 t
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 yo
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 deriv
the same AES256 encryption key (linkCodePairingECDHEncKeyCompanio
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 I
into a message (linkCodePairingWrappedPrimaryEphemeralPub) and sen
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 AES
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 secr
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 secre
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.

Thanks for reading Project Whitepaper! This

post is public so feel free to share it.

Initiating session setup

💡WhatsApp uses this “client-fanout” approach for transmitting messages to multiple devic
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 wi
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 ensu
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 devic
and doesn’t send messages to it.

Once the initiator has verified the keys and signatures for each device, it procee
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 Diffi

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 ever
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 buildin
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
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-bas
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" deriv
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 happe
adding an extra layer of forward secrecy.

Media & Attachments

1. Key Generation: For large files (e.g., videos or documents), a 32-byte AES256 ke
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 i
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
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 signat
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-on

Handling Missed Devices (Sender Side Backfill)

Device Mismatch: If a sender misses a recipient's devices, the server notifies th
to update the list.
Backfill Process:

The sender verifies new devices, establishes encryption sessions, and resen
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
value encryption, as well as for snapshot and patch integrity.

3. Collections and Patches:

Data changes are grouped into Collections which contain different data type
(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 tim
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-SHA
Base Roller: A server-side process that periodically compiles the changes into
Snapshots. This helps manage the data compactly and ensures that all devices c
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 t

app state are verifiable and resistant to tampering.
3. Patch Integrity:

Each Patch is verified by computing its HMAC over the individual mutatio
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 encryptio

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 expi
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. Th
introduction of App State Syncing and key rotation practices keeps user data
consistent and secure across devices. WhatsApp’s approach sets a strong example o
how encryption can protect digital communications while providing a seamless use
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=
7&_nc_sid=e280be&_nc_ohc=O2tQm3WgxAwQ7kNvgGsV9IS&_nc_zt=14&_nc_
=scontent.xx&_nc_gid=Ajs3MmvFB2FiOgRi21OSSSy&oh=00_AYAnlrpoO6e2H
ONEJ9R10YxrBgVASWsP4pl3Nxxi4nixg&oe=6771D699

Video covering the basic ideas -

 whatsapp security explained

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

Thanks for reading Project Whitepaper!

Subscribe for free to receive new posts and
support my work.

Type your email... Subscribe

3 Likes

Discussion about this post

Comments Restacks
Write a comment...

© 2025 Kitai Hazure ∙ Privacy ∙ Terms ∙ Collection notice

Substack is the home for great culture