It appears possible to sabotage a trusted setup ceremony.

[twister-dev]

Issue
Contribution verification doesn't verify the chain of contribution hashes that have been performed so far. Honestly, I think that an attack of this kind is unlikely, but the consequences could be bad.

The command snarkjs zkey verify <r1cs_file> <ptau_file> <zkey_file> verifies that the zkey is valid for a given constraints/ptau file, but it doesn't compare with expected previous hashes, and it doesn't have any way to do that by default.

I think the current defense against the described sabotage method below is prevented by manually reviewing the attestations and cross referencing the hashes of each file, but there's a way for the coordinator and contributors to use code to automatically detect an adversarial contribution during the zkey verification command. The coordinator would then pass the previous IPFS hash to a new contributor and ignore the malicious one.

Description of Sabotage

In the case that the attacker is not the coordinator

An attacker waits until near the end of the ceremony, then they upload their contribution file that's built from their own contributions, not from the most recent contribution file from the valid ceremony. They can forge other relevant data in their own attestation file, including by modifying the transcript to show the expected contribution hashes instead of the hashes in their own file.

Suppose there are N contributions total, the attacker waits M contributions before replacing the contribution file with their own, and then there are P contributions until the ceremony concludes, so M +1 + P = N contributions total. What should be a 1 of N trust assumption reduces to a 1 of P trust assumption, if none of the later contributors are adversaries. If the later contributors are in cahoots with an attacker, then the trust assumption can be even lower, possibly even compromising the entire ceremony. Of course the ceremony can be recovered by restarting at contribution M, if it gets discovered.

In the case that the attacker is the coordinator

The coordinator can simply forge the last contribution, and corrupt the entire ceremony. The contributors would require to compare their local files to the final zkey output of the ceremomy, which could feasibly escape detection.

Description of Possible Solution
Ultimately, the idea is that every participant, including the coordinator, should have a way to automatically detect forgery during or after the ceremony. I made something that tries to solve this with a custom logger that takes the list of previous contributions and compares those with the contribution hashes during the snarkjs zkey verify procedure.

The logic is straightforward. Inspecting zkey_verify_frominit.js, I see there's an optional logger argument to the js backend of the cli.

export default async function phase2verifyFromInit(initFileName, pTauFileName, zkeyFileName, logger) {

The script uses the info method on logger with contribution hashes in the zkey file:

if (logger) logger.info(misc.formatHash(c.contributionHash, `contribution #${i+1} ${c.name ? c.name : ""}:`));

This is the opportunity to check against the expected hashes. I wrote a logger that does this when I took a shot at making a trusted setup coordinator:

if (_hash !== this.contributionHashes.hashes[_index]) {
    const err = `Invalid Contribution Hash #${_index}\nFound:${_hash}\nExpected: ${this.contributionHashes.hashes[_index]}`;
    throw new Error(err);
}

The logger takes an object containing the contribution hashes so we would need to add a step to the ceremony for participants to update this list as well, possibly during the contribution phase. It might be better to verify the previous contribution file before performing the contribution, to outright prevent any honest contributor from building on a forged contribution.

I could be wrong about this being an issue, because of some step I'm misunderstanding or not seeing, but I hope this has been helpful.