update Grobner basis round calculation

[redshiftzero]

In a recent work Algebraic cryptanalysis of POSEIDON, the authors Ashur, Buschman, and Mahzoun demonstrate that the Grobner basis bounds in the original Poseidon paper are insufficient for high security bit levels.

In RoundNumbersBuilder::algebraic_attack_grobner_basis we compute the number of rounds to defend against Grobner basis attacks. We should update this based on the new result (see P. 12). The authors note that they were unable to find issues for the 128- or 256-bit security level so the round numbers shouldn't change for poseidon377, but since this parameter generation code is intended to be generic, we should update for the larger security level.

[hdevalence]

Won't this be a breaking change to the parameter generation? I'm not sure anyone is using other parameters generated from this crate but I'm a bit leery of changing the generation algorithm without versioning and giving access to the old implementation.

Maybe we should just roll the change into the ::v2 parameter generation codepaths, and leave ::v1 unchanged?

[redshiftzero]

Yep for high bit security levels it will be a breaking change, so we could for v1:

• Option 1: increment the major version to indicate a breaking change was made, though it might not be clear that it is to the parameter generation logic itself and not just the API,
• Option 2: as you suggest, leave the logic as is for v1. We should put a panic in for the impacted security bit lengths similar to as we did with MDS matrix generation for small field sizes: https://github.com/penumbra-zone/poseidon377/blob/f7e82aec42baf59725e5bb44280e33cb66543adc/poseidon-paramgen/src/mds.rs#L36 I'm not aware of any projects that are using such large security bit lengths, but it'll provide a guard nonetheless to prevent an insecure choice.

I'm cool with Option 2 and then folding in the updated Grobner basis constraint in with the v2 parameter generation.