References:
- [X3DH] The X3DH Key Agreement Protocol, Marlinspike and Perrin, 2016.
- [Double Ratchet] The Double Ratchet Algorithm, Perrin and Marlinspike, 2016.
- [Sesam] The Sesame Algorithm: Session Management for Asynchronous Message Encryption, Marlinspike and Perrin. 2017.
- [PQXDH The PQXDH Key Agreement Protocol, Kret and Schmidt, 2023
- [WhatsApp] WhatsApp Encryption Overview: Technical white paper, 2023.
- [CDGS] A Formal Security Analysis of the Signal Messaging Protocol, Cohn-Gordon et al. 2020
- [CCG] On Post-compromise Security, Cohn-Gorden et al. 2016
- [CPZ] The Signal Private Group System and Anonymous Credentials Supporting Efficient Verifiable Encryption, Chase et al. 2020
- [VGIK] On the Cryptographic Deniability of the Signal Protocol, Vantandas et al. 2021
- [BFGJS] Post-quantum Asynchronous Deniable Key Exchange and the Signal Handshake, Brendel et al. 2022
References DMA:
- [DMA gatekeeper obligations] Obligation for gatekeepers on interoperability
- [EU Law] EU DMA law
Signal Protocol¶
- Origins date back to TextSecure App started in 2010
- TextSecure used a double ratchet construction referred to as Axolotl Ratchet to highlight ''self-healing properties''
- TextSecure used a double ratchet construction referred to as Axolotl Ratchet to highlight ''self-healing properties''
- Later TextSecure was merged with RedPhone into Signal in 2015
- maintained by a non-profit organization called Open Whisper Systems
- 2018 Open Whisper Systems was transformed into Signal Foundation
- podcast with CEO Meredith Whittaker LNP504
Signal Protocol Usage¶
- Integrated into WhatsApp since 2016
- Also used by Wire, Facebook Messenger, Silent Circle, Pond, XMPP via OMEMO, ChatSecure, ...
| Messanger | Installations | Estimated Accounts |
|---|---|---|
| 9.64 Billion | ||
| Facebook Messenger | 5.89 Billion | ? |
| ... | ||
| Signal | 136 Million | ? |
Signal Protocol Design Goals¶
Aims to provide end-to-end encrypted (E2EE) conversations for asynchronous (mobile) messaging, as well as a series of other (informally stated) security properties, such as:
- End-to-End-Encryption (E2EE): This means that every message is encrypted such that only the intended recipient (respectively his device) can decrypt and read it [FAQ]. This is the most basic security property of any secure messaging application, yet it has to be defended constantly, e.g. in case of chat control in the EU [PatrickBreyer,EDRi,EFF], or the crypto wars [EFF].
- This is ensured by using secret keys that are only known by the respective communication endpoints.
- To prevent Machine-In-The-Middle [MITM] attacks, it has to be ensured that the correct (identity) keys of the communication partner are used!
- In Signal this is done by comparing the safety numbers
In cryptographic software, this type of thing is traditionally called a “fingerprint” rather than a “safety number.” While “fingerprint” is a well established and well understood term in the world of cryptography, user studies have shown that it’s a metaphor which doesn’t carry well outside of that community. People tend to associate “fingerprints” with sensitive personal information [Signal blog]
- Perfect Forward Secrecy (PFS): After a session has been established, this property ensures that an attacker that compromises one device (and thus has access to the long- and medium-term secrets) is not able to learn anything about the keys derived in previous sessions. In other words, the attacker is not able to decrypt previously sent messages he might have recorded in transit.
- Post Compromise Security (PCS): This property is also referred to as healing or future secrecy and was first formally described in [CCG]. It refers to the property that even if an attacker is able to compromise one device during a conversation for a limited amount of time, future conversations might still regain some protection.
- (Offline) Deniability: Refers to the ability that a party can deny having participated in a particular communication session in retrospect (sometimes also referred to as repudiation). Assuming a communication session between Alice and Bob, given a transcript of the communication it should not be possible for Bob to convince a third party that Alice has participated knowingly in the session.
Signal Protocol Overview¶
The Signal Protocol can be further devided into the following parts:
- X3DH (extended triple Diffie-Hellman) key agreement
- since late 2023 replaced by PQXDH, which is coceptually close but adds an additional post-quantum secure key encapsulation mechanism (KEM) into the key derivation function (KDF) to protect against harvest-now-decrypt-later attacks.
- Double ratchet algorithm
- since 2025 replaced by a PQ triple ratched referred to as ML-KEM Braid / Sparse Post Quantum Ratchet (SPQR), which relies on Sparse Continuous Key Agreement (SCKA) as introduced and described in the associated papers [USENIX25,Eurocrypt25] to maintain PFS and PCS against a quantum computer.
- Sesam session management for multi-device support, e.g., phone and desktop
- Group chats and private groups where the server has no record of group membership
Signal Protocol Implementations¶
Signal Protocol Implementations (unofficial)¶
There are also alterantive implementations, but their use is discuraged by the Signal foundation as they might be insecure:
- https://molly.im/
- presage
- signal-cli
- ...
- Telemessage SignalTM SGNL
- The signal fork used by officials in the case of "Houthi PC small group".
- Found to contain vulnerabilities: Micah Lee Blog, Wired
Signal Protocol Used Primitives¶
It uses the following cryptographic primitives:
- unkeyed primitives:
- SHA256 hashfunction
- symmetric primitives:
- HMAC-SHA256
- HKDF with SHA256
- Authenticated encryption with associated data (AEAD) using AES256 in CBC mode with PKCS#5 padding and HMAC-SHA256 as MAC
- asymmetric primitives:
X3DH and the Double ratchet¶
Modern messengers thrive to support the usage of multiple devices by the same user, e.g., a mobile app and a desktop client.
- leader based: The primary device -- typically a smart phone -- acts as a leader and serves as the EE2E endpoint pretending that there is only a single device per user. The leader device then distributes the messages, also in an encrypted way, to the other devices of the user, also referred to as companion devices [B].
- client fan-out: All devices of the user maintain their own key pair. For messaging, the sender creates an individual E2EE channel with each device of the receiver as if messaging multiple recipients [Sesam].
Digital Markets Act (DMA)¶
The Digital Markets Act (DMA) aims to ensure a higher degree of competition in European digital markets by preventing large companies from abusing their market power and by allowing new players to enter the market. This regulation targets the largest digital platforms operating in the European Union. They are also known as "gatekeepers" ... (soruce Wikipedia)
WhatsApp has been defined as a gatekeeper according to the DMA.
Any gatekeeper has to comply with certain obligations:
The gatekeeper shall make at least the following basic functionalities ... interoperable where the gatekeeper itself provides those functionalities to its own end users: ... (i) end-to-end text messaging between two individual end users; (ii) sharing of images, voice messages, videos and other attached files in end to end communication between two individual end users;
Any gatekeeper has to comply with certain obligations:
(b) within 2 years from the designation: (i) end-to-end text messaging within groups of individual end users; (ii) sharing of images, voice messages, videos and other attached files in end-to-end communication between a group chat and an individual end user;
Any gatekeeper has to comply with certain obligations:
(c) within 4 years from the designation: (i) end-to-end voice calls between two individual end users; (ii) end-to-end video calls between two individual end users; (iii) end-to-end voice calls between a group chat and an individual end user; (iv) end-to-end video calls between a group chat and an individual end user.
What about E2EE:
The level of security, including the end-to-end encryption, where applicable, that the gatekeeper provides to its own end users shall be preserved across the interoperable services.
Sound nice in theory, but how will this be implemented in practise?