You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
For the Shamir-based secret sharing approach we use, we could also the finite Galois field GF(2^256) which would provide us with a cleaner modulus that allows us to fit in 32 bytes of data into a single share. Unfortunately I couldn't previously find instantiations of this field anywhere.
Task
Replace the usage of the current prime-order field with an implementation of GF(2^256).
The text was updated successfully, but these errors were encountered:
After doing an investigation, I wasn't able to find a power-of-two field implementation in rust that would really work for what we need. Personally, I think this is low-priority because the field itself does not impact security, and the implementations that we have seem efficient enough.
Overview
Currently we use the default prime-order field that is provided in the https://github.com/zkcrypto/ff crate, i.e. the 255-bit that is used by the JubJub curve: https://github.com/brave-experiments/sta-rs/blob/main/sharks/src/share_ff.rs#L11-L15. We need to use such a large field to ensure that there are not collisions during the sharing process in the sta-rs protocol.
For the Shamir-based secret sharing approach we use, we could also the finite Galois field GF(2^256) which would provide us with a cleaner modulus that allows us to fit in 32 bytes of data into a single share. Unfortunately I couldn't previously find instantiations of this field anywhere.
Task
Replace the usage of the current prime-order field with an implementation of GF(2^256).
The text was updated successfully, but these errors were encountered: