Open bhgomes opened 2 years ago
It might have some issues if we require the RNG for AdditiveRoundConstants to be CryptoRng
, because LFSR itself is not necessarily a crypto RNG. Are we going to implement CryptoRng
trait for LFSR anyway?
Or shall we modify Sample
trait to release the CryptoRng
constraint? @bhgomes
It might have some issues if we require the RNG for AdditiveRoundConstants to be
CryptoRng
, because LFSR itself is not necessarily a crypto RNG. Are we going to implementCryptoRng
trait for LFSR anyway?Or shall we modify
Sample
trait to release theCryptoRng
constraint? @bhgomes
@tsunrise We can drop CryptoRng
from the requirements on Sample
. I figured this was going to happen eventually.
To improve the modularity and usefulness of the Poseidon Parameter Setup code, we want to separate the LFSR implementation from the field element sampling algorithm and the generation of the round constants and MDS matrix.
Old Design
Right now when generating the Poseidon parameters we have something like the following interfaces:
The issue with this design is that we are very restricted in our ability to utilize other sampling methods or PRNGs for constructing these types. We want to be able to leverage the existing random sampling APIs available in Rust and
manta-crypto
.New Design
For each type we have a structure that defines its own sampling methods.
Additive Round Constants
Maximum Distance Separable Matrix
Poseidon Hasher
Linear Feedback Shift Register PRNG
and in the Poseidon module:
where
BinarySize
is atrait
that tells us how many bits the field is made of (trait
name not final).Rejection Sampling Utilities
NB: The following must be defined in
manta_crypto::rand
.To plug these into the Poseidon parameter generation trait we just need to add the
TrySample<()>
implementation to thearkworks::Fp
field object then just call the standard parameter generation as: