This library has not undergone a formal security audit. It is research-grade software under active development.
Sumcheck is public-coin: prover messages depend only on the polynomial and verifier challenges. This library implements plain (non-ZK) sumcheck.
-
Standalone use (
gpublic): the transcript reveals everything the prover computes on. Timing side channels leak nothing beyond the transcript. -
ZK embedding (
gencodes witness data; ZK supplied by surrounding commitments/masking): the prover's arithmetic runs on secrets. A transcript-observing adversary is still safe, but resistance to local side-channel adversaries has not been formally verified. Fixed-size Montgomery multiplication is inherently data-independent, but this has not been audited, and no constant-time claim is made for arbitrarySumcheckFieldimplementations. Callers in that threat model must supply constant-time field operations.
sumcheck_verify checks round consistency and returns
SumcheckResult { challenges, final_claim }. It does not verify
that final_claim == g(r_1, ..., r_v) — this oracle check (Thaler Remark 4.2) is the caller's responsibility.
Forgetting the oracle check is a soundness bug. A malicious prover can craft round polynomials that pass all consistency checks but reduce to an arbitrary final claim. Without the oracle check, the verifier accepts.
Correct usage depends on the protocol context:
| Context | What the caller must do |
|---|---|
| Standalone | assert_eq!(result.final_claim, proof.final_value) |
| Composed (WHIR, GKR) | Pass result.final_claim to the next layer, which checks it |
| Custom (WARP) | Compute expected value from result.challenges and compare |
Outside of the SIMD path, the library contains no unsafe code. Within the
SIMD subsystem, unsafe is confined to two categories:
-
SIMD intrinsics (
core::arch) —_mm512_loadu_si512,vld1q_u64, etc. These areunsafeby definition in Rust; there is no safe alternative. They appear exclusively in the backend kernels (avx512.rs,neon.rs) and the evaluate/reduce loops that call them. -
Field ↔
u64reinterpretation — arkworks field types don't derivezerocopy, so the blanketSumcheckFieldimpl forark_ff::Fieldusestransmute_copyandfrom_raw_partsto reinterpret Goldilocks elements as their underlying Montgomery-formu64values. These are centralized in five trait methods (_to_raw_u64,_from_raw_u64,_as_u64_slice,_as_u64_slice_mut,_from_u64_components) infield.rs, each with a SAFETY comment documenting the invariant. The dispatch layer itself contains nounsafe.
Non-arkworks types using SimdRepr avoid category 2 entirely — the zerocopy
bounds (IntoBytes + FromBytes + Immutable) provide compile-time layout
verification, so no unsafe reinterpretation is needed.
The scalar (non-SIMD) code path uses no unsafe at all. If F is not a
recognised Goldilocks field, SIMD dispatch is skipped and the entire protocol
runs in safe Rust.
If you discover a security issue, please report it responsibly via private vulnerability reporting on this repository.
Do not open a public GitHub issue for security vulnerabilities.