Although ping pong keys are vulnerable to future quantum attacks, they are widely believed to be secure against today's attacks from classical computers. The Signal Protocol developers didn't want to remove them or the battle-tested code that creates them. This led to their decision to add quantum resistance by adding a third ratchet. This one uses the quantum-safe KEM to create new secrets, much like the Diffie-Hellman ratchet did before, providing quantum-safe security once compromised.
The technical challenges were far from simple. The elliptic curve keys generated by the X25519 implementation are about 32 bytes long, which is small enough that they can be added to each message without putting a strain on already limited bandwidth or computing resources. The ML-KEM 768 key, on the other hand, is 1000 bytes long. Additionally, Signal's design requires sending both the encryption key and the ciphertext, resulting in a total size of 2272 bytes.
And then there were three of them
To handle the 71x increase, Signal developers considered a variety of options. One was to send the 2272-byte KEM key less frequently—say, every 50th message or once a week—rather than every message. This idea was rejected because it does not work well in asynchronous or adversarial messaging environments. Signal protocol developers Graham Connell and Rolf Schmidt explained:
Consider the case of “send the key if you haven't sent it in a week.” If Bob has been offline for two weeks, what does Alice do when she wants to send a message? What happens if we lose messages and lose the one in fifty that contains the new key? Or what happens if there is an attacker in the middle who wants to stop us from generating new secrets and may be looking for messages that [many] bytes larger than the rest and discard them, only letting messages without a key through?
Another option that Signal's engineers considered was to split the 2,272-byte key into smaller chunks, say 71 of them, each 32 bytes long. Breaking the KEM key into smaller pieces and putting them in each message seemed like a viable approach at first glance, but again, the asynchronous messaging environment made it unworkable. What happens, for example, when data loss causes one of the fragments to be deleted? The protocol could handle this scenario by simply resending the fragments after previously sending all 71 fragments. But then an attacker snooping on the traffic could simply drop packet 3 each time, preventing Alice and Bob from completing the key exchange.
