01What is the Signal Protocol?
The Signal Protocol is an open cryptographic protocol for end-to-end encrypted messaging, designed by Open Whisper Systems (its work now continues under the non-profit Signal Foundation) and used by WhatsApp for all chats since 2016. It is built from two published algorithms: X3DH (Extended Triple Diffie-Hellman), which lets two devices agree on a shared secret even when one of them is offline, and the Double Ratchet, which keeps deriving new keys as the conversation continues.
Each device publishes an identity key, a signed pre-key and a batch of one-time pre-keys to the server. To start a session, the sender fetches that bundle, performs several Curve25519 Diffie-Hellman exchanges between its own identity and ephemeral keys and the recipient's keys, and runs the results through a key derivation function to get a root key. From then on the Double Ratchet turns two ratchets: a symmetric one that derives a new message key from a chain key for every message, and a Diffie-Hellman one that mixes in fresh key pairs whenever the conversation changes direction.
WhatsApp's encryption whitepaper describes each message key as 80 bytes — an AES-256 key, an HMAC-SHA256 key and an IV — used for AES-256 in CBC mode with HMAC authentication, and a sender-keys variant for groups. WhatsApp's servers store and forward only ciphertext. On the WhatsApp Business Platform the business end of the session is the Cloud API, which Meta operates as the business's data processor: it manages the keys, decrypts inbound messages and delivers them to your webhook over HTTPS. The protocol protects the path between the customer's phone and the Cloud API; the hop to your server is protected by TLS.
Key takeaways
- The Signal Protocol is the open cryptographic protocol behind WhatsApp's end-to-end encryption: X3DH key agreement plus the Double Ratchet.
- Every message is encrypted with a fresh key that is deleted after use, so a key stolen later cannot decrypt earlier messages.
- New Diffie-Hellman ratchet steps lock an attacker out again after a compromise, a property called post-compromise security.
- On the Cloud API the business end of the session is the Cloud API itself, which decrypts messages and forwards them to your webhook.
- The Signal Protocol is the mechanism; end-to-end encryption is the guarantee it delivers between two endpoints.
02 · How it works, step by step
How does the Signal Protocol work?
- Step 1
Publish a key bundle
On registration each device uploads its public identity key, a signed pre-key and a set of one-time pre-keys. The private halves never leave the device.
- Step 2
Agree a secret with X3DH
The sender fetches the recipient's bundle, combines its identity and ephemeral keys with the recipient's identity, signed and one-time pre-keys in several Diffie-Hellman calculations, and derives a root key and chain key with HKDF — no round trip with the recipient required.
- Step 3
Derive a key per message
The symmetric ratchet turns the chain key into a single-use message key and a new chain key using HMAC-SHA256. The message key encrypts one message and is then deleted.
- Step 4
Ratchet on every reply
Each time the conversation changes direction, the parties exchange new ephemeral Curve25519 keys and mix the result into the root key, so an attacker who copied earlier state is locked out again.
- Step 5
Verify identities out of band
Users can compare a 60-digit security code or scan a QR code to confirm no one substituted keys, and WhatsApp shows a notice when a contact's security code changes.
03The Signal Protocol: key facts and limits
- Key agreement
- X3DH over Curve25519
- Ongoing keys
- Double Ratchet: a new key for every message
- Message cipher (WhatsApp)
- AES-256-CBC with HMAC-SHA256
- Message key (WhatsApp)
- 80 bytes: 32 AES, 32 HMAC, 16 IV
- Identity check
- 60-digit security code or QR code
- Groups
- Sender keys, one chain per sender
- On the Cloud API
- Encrypted between user device and Cloud API
04The Signal Protocol in code
import hashlibimport hmacdef ratchet_step(chain_key: bytes) -> tuple[bytes, bytes]:"""One step of the symmetric-key ratchet, as WhatsApp's whitepaper describes it."""message_key_seed = hmac.new(chain_key, b"\x01", hashlib.sha256).digest()next_chain_key = hmac.new(chain_key, b"\x02", hashlib.sha256).digest()return message_key_seed, next_chain_key# The first chain key comes out of the root-key KDF after X3DH.chain_key = bytes.fromhex("6a09e667f3bcc908b2fb1366ea957d3e3adec17512775099da2f590b0667322a")for n in range(1, 4):seed, chain_key = ratchet_step(chain_key)# The seed is expanded with HKDF into 80 bytes: AES-256 key, HMAC-SHA256 key, IV.print(f"message {n}: key seed {seed.hex()[:16]}… used once, then deleted")
Teaching code only: the chain moves one way, so old message keys cannot be recomputed from the current state. Use libsignal, never your own implementation.
05Why does the Signal Protocol matter?
Developers integrating WhatsApp are asked about encryption in every security review, and vague answers such as "WhatsApp is encrypted" fail them. Knowing what the Signal Protocol actually guarantees — per-message keys, forward secrecy, servers that cannot read content — and where it stops lets you answer precisely: messages are encrypted between the customer's device and the Cloud API, and from your webhook onward the endpoint, storage and staff access are your responsibility, covered by TLS, encryption at rest and access control.
06Example: Answering a lender's security questionnaire
A Mumbai NBFC asks its WhatsApp integration team: "Is customer data encrypted end to end?" The precise answer has three parts. Messages are encrypted with the Signal Protocol between the customer's WhatsApp app and the Cloud API, which Meta runs as the NBFC's data processor. The Cloud API decrypts them and delivers them to the NBFC's webhook over HTTPS, where the signature is verified. Inside the NBFC, messages are stored in an encrypted database and only collections staff with the right role can read them. The auditor gets three accurate controls instead of one overstated claim.
07 · Common mistakes, and the fix
Common mistakes with the Signal Protocol
Claiming end-to-end encryption all the way to your database
With the Cloud API the Signal session ends at the Cloud API, and webhooks reach you over HTTPS. Describe that boundary accurately in security documents and protect your side with TLS, encryption at rest and access control.
Implementing the protocol yourself
Pre-key handling, skipped-message keys, state storage and header encryption are where the bugs live. If your own product needs Signal-style encryption, use the maintained libsignal libraries rather than re-implementing the maths.
Confusing forward secrecy with data deletion
Forward secrecy protects past messages if keys are stolen later; it does nothing for messages you store in plain text in a CRM, logs or backups. Your data retention rules still apply to everything you keep.
Ignoring identity changes
A changed identity key can mean a new phone — or someone else's. For sensitive flows, the Cloud API's identity change check withholds delivery when the customer's identity key has changed since you last stored it.
08 · Tips from the bench
Best practices for the Signal Protocol
- In questionnaires, write "encrypted with the Signal Protocol between the customer's device and the Cloud API" rather than a blanket "end to end".
- Read WhatsApp's current encryption whitepaper before quoting algorithm details; it is the authoritative source.
- Treat the webhook hop and your storage as separate controls: TLS in transit, encryption at rest, role-based access.
- Turn on the identity change check for high-risk messages such as payouts or account changes.