Closed redshiftzero closed 1 year ago
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?
Yep for high bit security levels it will be a breaking change, so we could for v1
:
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.
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 forposeidon377
, but since this parameter generation code is intended to be generic, we should update for the larger security level.