Skip to main content

Audits and Historical Issues

1. Why This Chapter Exists​

The Orchard implementation, Halo 2, and the Pasta curves were audited publicly before NU5 activated in 2022. A contributor working in audit-sensitive code (the circuit, the curve arithmetic, the key derivation) should read the relevant report before opening a PR. After this chapter the reader knows where to find each report and what classes of finding to expect.

2. Definitions​

Definition 2.1 (Audit-Point)​

A tagged commit submitted to an external audit firm. The git history of zcash/orchard carries branches named with -auditpoint suffixes that mark the snapshots reviewed by each firm.

Definition 2.2 (Recurring Finding Category)​

A class of vulnerability that appears across multiple reports. The five categories that recur in the Orchard / Halo 2 reports are listed in Section 4 below.

3. The Code​

3.1 Audit Reports​

The four publicly available reports most relevant to the crate:

3.2 Audit Page​

The Halo 2 audit overview links every report with a date and a scope. EC Co.'s blog post on the Orchard audit summarises the findings.

3.3 Tracing Fixes​

Most fixes are visible in the per-release sections of CHANGELOG.md and in the matching releases of halo2_proofs and pasta_curves. Commits between an audit-point branch and the next release are the audit-response commits.

4. Failure Modes​

Five recurring categories drive the audit findings. A contributor touching code in any of these areas should expect extra scrutiny.

  • Incomplete-addition reachability. Sinsemilla and the ECC chip use chord-and-tangent addition that is undefined on equal or opposite inputs. Every new domain or generator choice needs the unreachability argument (Halo 2 Book, Section on incomplete addition).
  • Witness canonicality. The prover must encode field elements into bits in exactly one way. Missing range checks in src/circuit/note_commit.rs or src/circuit/commit_ivk.rs is the textbook ambiguity bug.
  • Domain separation. Sinsemilla, Poseidon, RedDSA, and the transcript all use distinct personalisation strings. Any new domain must be checked for collision against all existing domains.
  • Side-channels in pasta_curves. Constant-time inversion and scalar multiplication were reviewed in pasta_curves. Bypassing the constant-time helpers (via bytes and manual reduction) reintroduces the risk.
  • Consensus-relevant constructor laxity. Identity-valued rk, ak, or cv are now rejected at construction (#492). A similar tightening for other types may be warranted; new types in src/keys.rs deserve a defensive constructor.

5. Spec Pointers​

6. Exercises​

  1. Pick one finding from the Least Authority report and locate the corresponding fix in this crate or in zcash/halo2. Cite the commit SHA.
  2. The incomplete-addition argument lives in the Halo 2 Book. Summarise in three sentences how Sinsemilla avoids the failure case.
  3. Code task. Read the unit test that exercises Action::from_parts after #492. Adapt it to cover a related rejection (e.g. an identity-valued nf) and confirm that the new test passes with the current constructor.

7. Further Reading​

  • The git branches named *-auditpoint mark the exact snapshot each firm reviewed; checkout one and diff against the next release to see the response.
  • The Halo 2 audits page is updated as new audits land.