What if your encryption software is working against you?

Fri, 02 Oct 2026 00:00:00 +0000

Suppose someone modifies your messaging app. You keep sending messages, your contacts keep receiving them, and everything decrypts correctly. There are no strange error messages. As far as you can tell, the app works.

Meanwhile, the implementation could be using those encrypted messages to leak your secrets.

I work on subversion-resilient cryptography, which studies what security we can retain when cryptographic implementations have been tampered with. One of the things I find most interesting about this area is that the malicious implementation may continue doing exactly what the user expects. The messages arrive. The signatures verify. The extra information escapes through choices the user never sees.

That makes the problem rather uncomfortable. It also leads to a surprising question: can we protect a user from their own cryptographic software without giving another party access to their secrets?

How a valid ciphertext can leak a key

Consider an encryption scheme that uses fresh randomness. Encrypting the same message twice can produce different ciphertexts, both of which decrypt to the same message. This is ordinary behaviour for a randomised encryption scheme.

Now give the implementation a malicious objective. It wants to leak one bit of a secret key while still encrypting the user’s message correctly.

For a deliberately simple example, fix the key and message. Suppose a public test on the ciphertext returns 0 or 1 with equal probability over honestly sampled encryption randomness. The modified implementation encrypts the message and runs the test. If the result matches the secret bit it wants to leak, it sends that ciphertext. Otherwise, it tries again with fresh randomness.

Each attempt succeeds with probability one half, so it takes two attempts on average. The recipient decrypts the intended message. An observer who knows the selection rule reads the leaked bit from the ciphertext. That is a rather cheap price for leaking a bit of a key.

This example is deliberately crude. Its purpose is to make the channel visible; it does not establish that the attack would evade statistical analysis. More sophisticated algorithm-substitution attacks use cryptography to conceal the selection rule. Bellare, Paterson and Rogaway studied this problem formally in their work on symmetric encryption and mass surveillance.

A test that checks whether decryption recovers the original message would pass in this example. To notice the problem, we would need to examine how the implementation chooses among the many ciphertexts that pass that check.

What happened to the security proof

There is no contradiction with a proof that the encryption scheme is secure. Such a proof concerns specified algorithms and assumptions about how they are executed. If the encryption algorithm is supposed to sample randomness uniformly, the proof relies on that step.

Our malicious implementation changes the distribution by discarding outputs it does not like. It is executing a different algorithm, even though each ciphertext it eventually releases remains valid.

That distinction matters. Correct decryption tells us that a ciphertext represents the right message. It does not tell us that the process which produced the ciphertext respected the assumptions of the security proof.

Subversion resilience asks us to model that malicious process explicitly and establish what protection remains possible.

Changing a message without reading it

A cryptographic reverse firewall sits between a participant and the outside world and transforms protocol messages. Mironov and Stephens-Davidowitz introduced the model at EUROCRYPT 2015. The firewall receives public information and protocol traffic, without being given the participant’s private input or secret keys. Its transformations must preserve the intended protocol functionality.

The name can be misleading if it makes you picture a filter searching packets for suspicious contents. In our example, a ciphertext carrying a hidden key bit is also a perfectly valid encryption. There need not be a distinctive bad packet to recognise.

A useful technique is rerandomisation. Certain encryption schemes allow a ciphertext to be transformed into a fresh encryption of the same message without decrypting it. Textbook ElGamal is an example. For a fixed message, adding independent uniform randomness removes the original sender’s control over the encryption randomness.

Return to the toy attack. The malicious implementation carefully chooses a ciphertext for which the public test returns 1. If a suitable rerandomisation step produces an independently distributed encryption of that same message, the test on the outgoing ciphertext is again equally likely to return 0 or 1. The carefully selected bit has been lost.

The firewall does not need to discover which secret the implementation was trying to leak. It changes the representation in a way that destroys the illustrated channel while retaining the message.

In the toy example, rerandomisation removes the app’s control over the publicly readable bit without changing the encrypted message.

That is a useful building block. A complete protocol needs much more care: its messages may be authenticated, influence later keys, or carry state that other participants expect to remain consistent. The transformations have to be designed together with those requirements.

Where the trust goes

At this point, a reasonable objection is that I have introduced another piece of software that might also be compromised.

The distinction is in the security cases. Protection from a subverted implementation requires a correctly operating firewall. When the participant’s implementation is honest, a malicious firewall has the powers of an active network attacker, which the underlying protocol must already withstand. The firewall is not entrusted with the user’s secret keys.

These statements do not promise security when the attacker controls both components. Nor do they promise delivery through a firewall that simply drops every message.

It also puts a practical question on the table. If the firewall runs in an environment that the compromised application can modify freely, what independence have we actually gained? The deployment has to make the separation assumed by the cryptography meaningful.

From one ciphertext to a conversation

A conversation introduces a different level of difficulty. People send messages while their contacts are offline. Messages can arrive out of order. Keys evolve over time.

Ratcheting protocols aim to limit the damage from key exposure. Forward secrecy protects earlier messages from a later compromise of the current state. Post-compromise security concerns recovering protection for future messages once the attacker no longer has the access needed to follow the evolving keys and suitable fresh secret material enters the protocol. Those guarantees have conditions. By themselves, they do not protect an implementation that keeps leaking the newly generated keys.

Now imagine allowing an intermediary to transform some of the messages that drive that evolution. Will both participants still compute compatible keys? Can we preserve authentication? What happens after an attacker interferes? A transformation that looks harmless in isolation can affect the rest of the conversation.

In Guarding the Signal, our CRYPTO 2025 paper with Yevgeniy Dodis, Noah Stephens-Davidowitz and Yiannis Tselekounis, we construct a Signal-style messaging protocol with reverse firewalls, including X3DH-based initial key agreement.

The firewall sanitises key-agreement traffic. For message encryption, fixing the key, message and associated data fixes the only accepted ciphertext, removing the choice exploited in the toy attack. Forward secrecy and post-compromise security hold under our model. Deployment requires changes to the messaging protocol.

Constraining the ciphertext alone would leave another problem. An implementation that could arrange for the encryption key to be known to the attacker would still compromise confidentiality. Requiring a unique ciphertext under that key would not help. This is why protecting key agreement and controlling the encryption layer have to work together.

Refreshing one encrypted value is a neat algebraic operation. Preserving the guarantees of an ongoing conversation requires reasoning about what that operation changes everywhere else.

The assumptions are part of the result

Suppose a malicious application replaces the message you intended to send with your private key. A component that preserves an encrypted message without learning its contents cannot generally determine that you meant to say something else. Protecting the meaning of a user’s input requires a way to establish what that input was.

Our model requires subverted implementations to preserve functionality and be explainable: their messages must be consistent with honest execution on the same inputs and incoming messages, using possibly malicious randomness. Biased randomness and rejection sampling remain possible; deliberately generating invalid messages to signal secrets is excluded. Timing and other side channels are outside the model.

Similarly, a firewall on one communication path has no control over a second path that bypasses it. If malware can read plaintext and send it elsewhere, a guarantee about transformed protocol messages does not address that escape route.

Making the model survive implementation

This is what we should be asking now: would these assumptions survive contact with a real system?

Where should the firewall run? How does it obtain independent randomness? Which messages can it see and transform? How do we ensure that the application cannot quietly use another route?

Our paper leaves open how to apply these transformations when an additional encryption layer, such as TLS, hides the relevant traffic.

That is the level of security the community should aim for: protocols with guarantees that remain useful even when the implementation is part of the problem.

Reverse Firewalls |