Add parameter verification to zcashd distribution (Sapling)

[matthewdgreen]

The Zcash Sapling parameter generation ceremony is designed to ensure the correct structure of all Zcash zkSNARK proving parameters. This is conducted using a combination of pairing checks and efficient ZK proofs. Parameter validation is important (and an essential part of the system design) because failure to ensure valid parameters can lead to violation of ZK properties in the zkSNARK.

For users not involved in the Sapling generation process, Zcash proposes to publish a separate parameter verification tool that allows third-party users to check that the parameters are correctly structured. However, at the time of this filing (10/2/18), the equivalent parameter verification scripts are not published for Zcash Sprout. While this does not present a critical security issue, the apparent difficulty in maintaining availability of this code represents a violation of a user promise: parameters should be easily verifiable by all users who rely on them.

To simplify the distribution of this verification code, I propose that the parameter verification logic be included in either (1) the zcashd binary, or (2) the "fetch_parameters.sh" scripts distributed with zcashd. Because verification is time consuming, it need not be a requirement. It could be activated with a flag as follows:

zcashd --verify-params

Or

fetch_params.sh --verify

As a result of these optional flags, the scripts would conduct a full verification of the parameter structure to ensure user confidence in the anti-subversion countermeasures. Any failure of verification would cause either (1) zcashd to exit(1) with a clear error, or (2) the parameter fetch to fail. The parameter verification checks should also be included as tests in the CI behavior of zcashd and the distribution.

Update: Just to be clear, I'm talking about anti-subversion checks -- not a full MPC transcript verification.

[daira]

It's not the case that we didn't publish the scripts for the Sprout MPC verification; they are present in the https://github.com/zcash/mpc repo. The files that are currently missing and needed for reverification are r1cs (describing the circuit) and transcript (the MPC transcript).

[daira]

Note that it is not possible to reverify the ceremony without the transcript, which is very large, and impractical to include with zcashd. It is possible to reverify the subversion-ZK property with a much smaller amount of data (perhaps just the parameters, I'm not sure), but not the knowledge soundness property.

[tromer]

I support this, as a way to ensure that verification code is readily available to any interested user, and is distributed by channels that users already trust.

However, it bears noting that in practice it's not necessary for all users to verify the parameters. It's sufficient that a large enough set of independent users (or the software packagers that users trust anyway) have verified the parameters and have the ability to broadly communicate a verification failure.

[tromer]

@daira, verifying soundness also requires checking that (sufficiently many) ceremony participants weren't dropped from the transcript. That requires (sufficiently many) participants to check the transcript and shout out if their contribution is amiss, or alternatively, comparing the transcript to the archives of the mailing list (or similar) used to report participation. This, too, requires tool support.

[matthewdgreen]

@daira: All I'm referring to in this thread is subversion issues. To avoid subversion issues, all you need to do is conduct pairing checks on the FINAL parameters. You do NOT need the full transcript. This is actually a subroutine in (various versions) of the Zcash parameter setup process. It may require some extra data, but it's still worth doing in fetch_params.sh.

[tromer]

@matthewdgreen, a terminological nitpick: "subversion" is not the right term to distinguish, since the paper that introduces the term defines both subversion soundness and subversion zero knowledge.