Cryptography |

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.

Can you edit a blockchain without breaking the chain?

Fri, 25 Sep 2026 00:00:00 +0000

Suppose a shared ledger accidentally includes a confidential document. Everyone agrees it should not be there. Someone appends a correction asking readers to disregard it.

The correction does not remove the document. New participants still receive it when they download the history. Existing participants still carry it as part of the accepted record.

That is an uncomfortable consequence of a property blockchains are often designed to provide: once a record becomes part of the agreed history, changing it should be difficult.

In work with Giuseppe Ateniese, Daniele Venturi, and Ewerton Andrade, I explored a different design choice. Could a blockchain permit explicitly authorized changes to old content while preserving the cryptographic links connecting its blocks? Our paper, , first appeared as a preprint in 2016 and was published at IEEE EuroS&P 2017.

The answer depends on separating two questions: how an edit can preserve the chain, and who should be allowed to make that edit.

Why changing an old block causes trouble

A blockchain links blocks through cryptographic hashes. A later block contains a reference derived from the previous block. If the earlier content changes, its hash normally changes too, and the later reference no longer matches.

Updating that reference changes the later block, which affects the block after it. In a proof-of-work chain, reconstructing a valid replacement history also involves the work associated with those altered blocks. A seemingly local correction can therefore become a problem for everything that follows it.

Adding a new record is often the right application-level answer. A reversal can record that a payment was cancelled, for example, while preserving the evidence of what happened. But an appended correction and removal of old bytes serve different purposes. The former does not achieve the latter.

The paper’s construction asks whether an authorized editor can change a block’s content while preserving the value used to link to it. That is the role of a chameleon hash.

A hash with a controlled way to find collisions

An ordinary collision-resistant hash should make it infeasible to find two different inputs with the same output. A chameleon hash has a public hashing key and a secret trapdoor. Without the trapdoor, finding collisions should remain hard. With it, an editor can efficiently arrange a collision for a chosen replacement message.

For a public-coin chameleon hash, the idea can be written schematically as:

CH(m, r) = CH(m′, r′)

Here, m is the original content and r its randomness; m′ and r′ are their replacements. The public hashing key is omitted from this notation. Anyone can check the equality. Producing the new randomness for a chosen replacement is the operation that requires the trapdoor.

In the blockchain construction, the chameleon hash covers the content that may need to change. Its output feeds the hash used for the block’s proof of work and the next block’s reference. Preserve the chameleon-hash output and keep the proof-of-work nonce fixed, and that outer hash stays the same as well.

The authorized edit changes the content and its associated checking information. It does not force every later block to acquire a new reference or a new proof of work. The construction retains an ordinary hash in the outer layer; it does not give editors a way to find arbitrary collisions in SHA-256.

An authorized editor changes the middle block’s content and randomness while preserving the link value. In the construction, an unchanged chameleon-hash output and nonce also preserve the outer proof-of-work hash.

An edit must not give everyone the editing key

There is a trap here. Some chameleon-hash constructions expose their trapdoor when someone sees a collision. That can be acceptable in applications where collisions remain private. It is a serious problem for a publicly edited ledger.

A participant might retain the original block and then receive its replacement. It now has two different messages and their checking information under the same hash value. If that pair reveals the trapdoor, one authorized edit would give observers the power to make further edits themselves.

The required property is therefore stronger than ordinary collision resistance. Seeing authorized collisions must not enable an observer to generate unauthorized ones. The paper formalizes this as enhanced collision resistance, addressing the key-exposure problem.

One contribution is a generic transformation using encryption and a suitable non-interactive zero-knowledge argument. Instead of exposing the underlying hashing randomness directly, the transformed hash publishes an encryption of it and a proof that the encrypted value is consistent with the message and hash. Verification remains public while the randomness itself is hidden. An authorized editor can recover it and generate the replacement checking information.

That construction has its own assumptions and proof requirements. It is also distinct from the efficient public-coin construction used elsewhere in the paper for the distributed protocols and prototype. The paper provides both the stronger general construction and concrete ways to explore the blockchain integration.

Who holds the power to edit?

Knowing how to preserve a link does not decide who may change the record behind it.

In the simplest setting, one designated authority holds the trapdoor. That authority can generate the collisions needed for redaction, and the system needs rules for authenticating its changes and adopting the updated chain.

The paper also describes a distributed setting. A designated group holds shares of the trapdoor and uses secure multiparty computation to produce a redaction. The aim is to obtain the replacement checking information without handing the full editing key to an individual participant. The security guarantees depend on the chosen sharing and computation protocols, including their assumptions about how many participants may be dishonest.

This arrangement gives a consortium a way to distribute authority. It does not make authority disappear. The group still needs a membership policy, a decision process, and a response to compromised or unavailable key shares.

The distinction becomes especially important in an open network. The paper discusses distributing the key among network participants or a selected subset, while acknowledging the performance difficulties of a large group. Choosing that group and maintaining it over time are deployment questions. A shared trapdoor is not, by itself, a complete governance system.

For a deployment, the editing policy must also say which transformations preserve the application’s meaning. Maintaining hash links does not establish that an arbitrary rewritten payment history is economically consistent or that every transaction dependency remains valid. The cryptographic mechanism is one part of the system’s acceptance rules.

What can an observer learn about the edit?

There are two different observers to consider.

An existing participant may have the old block and receive the proposed replacement. It can compare the versions and take part in whatever approval or auditing process the system specifies.

A newcomer may see only the redacted chain. The paper’s history-independent design aims to prevent that current representation from revealing the previous content. It therefore does not automatically provide a permanent, self-contained record of every edit to every future reader.

These are different requirements. A system that wants an enduring indication that a redaction occurred must design for it. The paper discusses a later permissioned prototype with an immutable indication of alteration; that additional behavior should not be confused with the guarantees of the basic history-independent construction.

There is a more fundamental limit too. Redacting the agreed ledger cannot erase copies that someone already saved. A participant could archive the original chain or copy the document elsewhere. The mechanism lets cooperating participants change the maintained record; it cannot make every observer forget the past. The paper explicitly acknowledges this distinction.

What the Bitcoin prototype demonstrated

The paper includes a proof-of-concept implementation built on Bitcoin Core 0.12. It changes block hashing and extends the header to carry the chameleon hash’s randomness. It implements block redaction and removal in a centralized setting, with one special node holding the trapdoor.

Those details matter when reading the performance results. The experiments ran on a private regression-test network. They measured in-memory operations, excluded disk access, and removed the proof-of-work cost from the block-creation comparison. In that setting, the paper reports a small, nearly constant additional cost for creating blocks.

This demonstrates feasibility for the tested operations. It does not measure the full cost of distributing edits across a production network, running a maliciously secure multiparty redaction protocol, or administering the editing authority.

It also does not show that an ordinary Bitcoin node would accept the modified chain. The prototype uses a different block structure and hashing rule. The paper describes an initialization procedure for migrating an existing chain. Adopting the scheme requires an explicit protocol change, rather than a secret key that somehow edits the existing Bitcoin ledger.

The guarantee has changed

The appeal of an immutable ledger is that an administrator cannot quietly rewrite yesterday’s record using an ordinary database command. Introducing a redaction trapdoor deliberately changes that guarantee.

The resulting promise is conditional: parties without the required authority should remain unable to rewrite the chain, while authorized participants can perform the changes the system permits. Whether that is desirable depends on the application and its trust model.

For me, the useful question raised by this work is how precisely we can state those boundaries. Which content can change? Who can approve it? What evidence survives? What happens if the editing authority is compromised?

Chameleon hashes give a technical answer to preserving the chain through an edit. A useful deployment must give equally explicit answers about the people and procedures controlling that capability.