In src/groth/vk.ts:62-68, when parsing a Groth16 verification key, we detect available IC points by scanning for keys matching the pattern ic\d+ and sorting them numerically. However, we never validate that the detected IC indices form a contiguous sequence starting from 0.
This means a malformed VK with fields {ic0, ic1, ic3} (missing ic2) would be silently accepted. The resulting icPoints array would have 3 elements mapped to internal indices [0, 1, 2], but the original ic3 data would be treated as if it were ic2. This is a silent data corruption — no error is thrown and the proof verification would use the wrong public input commitments.
There is already a FIXME CHECKME comment on line 97 acknowledging this concern.
Expected Behavior
Parsing should validate that IC fields form a contiguous range [ic0, ic1, ..., icN] with no gaps. If any index is skipped, parsing should throw a descriptive error.
Notes
The fix itself should be straightforward — a contiguity check after sorting the detected fields
In src/groth/vk.ts:62-68, when parsing a Groth16 verification key, we detect available IC points by scanning for keys matching the pattern ic\d+ and sorting them numerically. However, we never validate that the detected IC indices form a contiguous sequence starting from 0.
This means a malformed VK with fields {ic0, ic1, ic3} (missing ic2) would be silently accepted. The resulting icPoints array would have 3 elements mapped to internal indices [0, 1, 2], but the original ic3 data would be treated as if it were ic2. This is a silent data corruption — no error is thrown and the proof verification would use the wrong public input commitments.
There is already a FIXME CHECKME comment on line 97 acknowledging this concern.
Expected Behavior
Parsing should validate that IC fields form a contiguous range [ic0, ic1, ..., icN] with no gaps. If any index is skipped, parsing should throw a descriptive error.
Notes
The fix itself should be straightforward — a contiguity check after sorting the detected fields