fix: harden BN254 G2 SRS ingress

[suyash67]

Summary

Tightens the BN254 G2 SRS load path with four layered defenses, addressing an audit finding around G2 input validation.

• add subgroup check on g2 points — implements affine_element::is_in_prime_subgroup() (textbook [r]·P == O check) and applies it at every G2 entry point. Catches G2 inputs that lie in a cofactor subgroup of E'(Fq2) but happen to be on-curve.
• pin SHA-256 of g2 SRS bytes and verify on disk load — bakes the canonical Aztec [x]_2 bytes (BN254_G2_ELEMENT_BYTES) and their SHA-256 (BN254_G2_ELEMENT_SHA256) into the binary as constants, mirroring the existing G1 chunk-hash mechanism. get_bn254_g2_data now hash-compares the on-disk payload before deserialization, so a tampered bn254_g2.dat is rejected before its bytes can reach any verifier. Also implements the previously declaration-only get_bn254_g2_data.
• reject g2 = point at infinity — explicit gate against [x]_2 = O. Infinity is in every subgroup (so the subgroup check passes) and e(−W, O) = 1 collapses the KZG pairing equation. Strictly redundant with the hash pin, but kept as defense-in-depth so any future loosening of the hash gate (e.g. a "custom SRS" flag) does not silently reopen the issue.
• reject off-curve points in is_in_prime_subgroup — guards the primitive itself: the Weierstrass group law is unsound for off-curve coordinates, which means the [r]·P trick can return a false positive on a point satisfying y² = x³ + b' for some b' ≠ b with a prime-r factor in its order. One squaring up front closes that gap and protects every existing and future caller.

Threat model

The hash pin promotes the on-disk SRS bytes to the same trust level as the binary itself. Concretely, the attack vectors closed:

• MITM on the plain-HTTP CRS download from crs.aztec-cdn.foundation
• Compromise of the CDN bucket (R2/S3 key leak, BGP hijack)
• Local cache tampering by a same-user-but-not-root process (Docker volume mounts, sibling processes, backup tooling)

None of these require the attacker to patch the verifier binary itself.

Test plan

• srs_tests — all CrsFactory.* pass, including new Bn254HardcodedG2IsInPrimeSubgroup, Bn254G2HashMatchesPinnedBytes, Bn254G2DataLoadsAndVerifies, Bn254G2CorruptionDetected, Bn254G2InfinityRejected
• ecc_tests — full suite (843 tests) passes, including new g2.IsInPrimeSubgroupAcceptsSubgroupPoints, g2.IsInPrimeSubgroupRejectsCofactorPoint, g2.IsInPrimeSubgroupRejectsOffCurvePoint (regression test for the off-curve guard) and the typed IsInPrimeSubgroupAcceptsSubgroupPoints
• Compiles clean with ninja srs_tests ecc_tests

[suyash67]

Question for @ludamad: this function was unimplemented before. I've implemented it to check if g2 point:

• is not a point at infinity
• is in the prime-ordered subgroup
• the sha256 matches with the canonical $[x]_2$

Do we need to keep the boolean allow_download to allow g2 data to be downloaded if all of the above checks fail (like we do in g1 data)?

[ledwards2225]

LGTM. I think pairing this with my PR validating the actual trusted setup data would allow a paranoid user to confirm that everything is kosher but in practice this is probably the more useful line of defense