[Audit C-03] Decryption proofs are replayable across unrelated E3 contexts

[hmzakhalid]

Finding

Severity: Critical

Confirmed against baseline commit d4277510d. The baseline tracked publication only per E3 and did not consume a canonical proof nullifier, so the same valid decryption proof could be reused in another compatible E3 context.

C-03 — Decryption proofs are replayable across unrelated E3 contexts

Affected code: contracts/interfaces/IDecryptionVerifier.sol:8-64,
contracts/verifiers/bfv/BfvDecryptionVerifier.sol:34-39,95-154,
contracts/Interfold.sol:443-459

BfvDecryptionVerifier.verify checks the recursive VK hashes, committee hash,
and plaintext coefficients. It explicitly discards e3Id, committeeRoot,
sortedNodes, ciphertextOutputHash, and committeePublicKey. It also has no
chain ID or verifier-deployment domain input. This contradicts the interface's
claim that the proof is bound to the full on-chain context.

A proof of plaintext P for ciphertext/key/E3 A is accepted for E3 B whenever B
supplies the same committee hash and claimed plaintext hash—even if the E3 ID,
root, nodes argument, ciphertext, and key are different. Cross-chain or
cross-deployment replay is also possible when verifier anchors and committee
hash match.

Proof of concept: AUD-C03 invokes the same proof against two calls with
different E3 IDs, roots, nodes, ciphertext hashes, and public keys; both return
true.

Recommendation: Add a domain/context commitment to the decryption circuit's
public inputs. A single canonical commitment may bind
(block.chainid, address(verifier or Interfold), e3Id, committeeRoot, committeeHash, ciphertextOutputHash, committeePublicKey, plaintextOutputHash, circuit/version domain).
The wrapper must recompute and compare it. Ensure the value is actually
constrained inside the recursive proof chain, not merely appended by an
untrusted aggregator. Add negative tests changing each field independently and
cross-chain/cross-deployment replay vectors.

Required remediation

Consume a canonical decryption-proof nullifier derived from its public inputs and reject cross-E3 proof reuse, with dedicated replay regressions.

The dedicated fixing commit and remediation PR will be linked in a follow-up comment.

[hmzakhalid]

Fixed by commit d35262a4ddb29ab4d3e450b1304a77c34fea3666 in PR #1727.

[hmzakhalid]

Supersedes the earlier remediation reference after the cleanup of PR #1727. Fixed by commit ca21aed (C-03): canonical single-use proof nullifiers block reuse across E3s in one Interfold deployment. Circuit-level domain binding across independent deployments remains explicit future hardening.

[hmzakhalid]

Final C-03 SHA after the C-02 history cleanup: 89454d6.

[hmzakhalid]

Final C-03 SHA after the C-01 lockfile fixup: f577ce8.

[hmzakhalid]

Final fixing commit after the branch history rewrite: 73db32e (73db32e).

[hmzakhalid]

Supersedes the earlier commit reference after the C-01 history correction: C-03 is fixed by 367667d.

[hmzakhalid]

Superseding the storage-nullifier approach from 367667d451c176abb5365201127ee90877c128b3.

The underlying problem is not merely that the same proof bytes can be submitted twice. It is that the proved statement was not cryptographically tied to the E3 context in which the proof was consumed. A global keccak256(proof) nullifier only makes one serialized proof payload one-shot within one contract deployment. It does not make the statement itself specific to an E3, chain, or Interfold deployment, and it adds permanent storage growth, extra gas, state-management complexity, and brittle manual storage-slot coupling through the linked InterfoldPricing library.

The stronger fix is now implemented in c6cb4d17e63b99ca159e88feb750a28c977eb043:

• The protocol computes keccak256(abi.encode(chainId, interfoldAddress, e3Id, committeeHash, ciphertextOutputHash, committeePublicKey)).
• Its two 128-bit limbs are public inputs to every secret-bearing C6 share-decryption proof.
• C6 recursive folding requires every folded proof to carry the same domain.
• The final DecryptionAggregator exposes that domain as public inputs.
• Interfold recomputes the expected domain onchain, and the BFV verifier wrapper requires the final proof's public inputs to match it.

This is cryptographically stronger because an existing proof cannot simply be relabeled for another E3, chain, deployment, committee, ciphertext output, or committee key. Producing a proof for a different domain requires regenerating the underlying C6 proofs using the ciphernodes' secret key-share witnesses. The protection is stateless, so there is no consumed-proof mapping, no unbounded nullifier storage, and no manually hard-coded Interfold storage slot.

The generated DecryptionAggregator verifier was regenerated through the normal circuit toolchain rather than hand-edited. The associated predeployment storage snapshots are refreshed in 1bb7970839866b9b03e670672eb9308d4dfd706e.

[hmzakhalid]

Confirmed fixed cryptographically in 112eb75. C6/decryption proofs are domain-bound to chain, Interfold deployment, E3, committee, ciphertext, and committee public key. The global nullifier and manual storage-slot write were removed; domain separation prevents cross-context replay at the proof layer.

[hmzakhalid]

Final remediation in PR #1727: 112eb75 binds decryption proofs to the E3 domain through the circuit/verifier chain, and a550e46 makes the canonical address ordering explicit across the protocol.