fix: sanitize groth16 verification key reading

[ivokub]

Description

See the related security advisory https://github.com/Consensys/gnark/security/advisories/GHSA-cph5-3pgr-c82g (will publish once PR has been reviewed and tested) for full description and POC.

The main issue is that serialized Groth16 verification key includes in a header number of expected Pedersen verification keys which is used for initializing a slice. When modifying the serialized file, we may allocate huge slice, leading to OOM.

In this PR instead of allocating the slice beforehand, we instead try to read all the existing commitment keys in the file and then compare that the number of read commitment keys corresponds to the expected. This prevents using heuristics on the number of commitment keys and bounds the size of the in-memory full verification key to the serialized file size.

Type of change

• Bug fix (non-breaking change which fixes an issue)

How has this been tested?

Tested against the POC in the advisory. Does not OOM anymore.

Checklist:

• I have performed a self-review of my code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• I have added tests that prove my fix is effective or that my feature works
• I did not modify files generated from templates
• golangci-lint does not output errors locally
• New and existing unit tests pass locally with my changes
• Any dependent changes have been merged and published in downstream modules

[ivokub]

@gbotrel - it is done now :) I didn't anticipate making that much bugs :/

[gbotrel]

lgtm, suggestion for perf to avoid many re-allocations in some cases