12th field extension #14
Conversation
…into tristan/12th-field-extension
| @@ -17,7 +17,7 @@ edition = "2021" | |||
| hex-literal = "0.4.1" | |||
| num-traits = "0.2.19" | |||
| subtle = "2.6.1" | |||
| crypto-bigint = { git = "https://github.com/RustCrypto/crypto-bigint.git"} | |||
| crypto-bigint = { git = "https://github.com/RustCrypto/crypto-bigint.git", features = ["rand_core"]} | |||
There was a problem hiding this comment.
Huh, didn't know we could source a crate from git but makes sense.
There was a problem hiding this comment.
ye! I pulled from git to get the latest since the ConstMontyForm is apparently not in the version published on cargo, which we need for our case
| @@ -138,6 +144,12 @@ macro_rules! define_finite_prime_field { | |||
| fn square(&self) -> Self { | |||
| (*self) * (*self) | |||
| } | |||
| fn rand<R: CryptoRngCore>(rng: &mut R) -> Self { | |||
| Self::new(<$uint_type>::random_mod( | |||
There was a problem hiding this comment.
So we're using some object that implements RandomMod to call this?
There was a problem hiding this comment.
yeah, this object ends up being crypto_bigint::rand_core::OsRng, which is guaranteed to be a constant time thread_rng for execution on a modular form
There was a problem hiding this comment.
the actual method is random_mod, which is defined on every unsigned integer type in crypto_bigint, and accepts as a parameter an rng that satisfies the CryptoRngCore trait, which is why it is passed in as a generic in the fn definition. the function prototype then reads "a function rand that accepts as an input argument a mutable reference to an object that satisfies the CryptoRngCore trait`
| let wide_p = u256_to_u4096(&Fp::characteristic()); | ||
| let wide_p2 = wide_p * wide_p; | ||
| let wide_p6 = wide_p2 * wide_p2 * wide_p2; | ||
| wide_p6 * wide_p6 |
There was a problem hiding this comment.
Huh, I thought the characteristic of any finite field had to be a prime p, not a power.
There was a problem hiding this comment.
well its a bit of a subtlety, because these extensions are fields, but they're not prime order since they're generated from a quotient polynomial ring over a base field, so their representations are some linear combination of base prime fields which means they can have an arbitrary factorization
There was a problem hiding this comment.
this is also a reason why, when we start talking about groups on these fields, that we want to get the smallest prime-order subgroup of the elliptic curve group defined on these fields. in any case, this entire method is not even used in the code for the extensions, and so I can axe it if its too confusing, I just included it for completeness / debugging but I ended up not using it. thoughts on axing?
There was a problem hiding this comment.
I suppose it boils down to whether any user could find the method useful, even if for informational purposes. If mathematically correct and not relevant to the correctness or performance of anything we're doing, I have no problem with it remaining.
This finishes implementing the 12th order extension for the BN254 tower.
Wahoo!
The reference cases are much more laborious to test with sage (generation time of the quotient polynomial ring of order p^12 (a U4096 integer) is very slow, but doable.
This also implements random element generation in each level of the tower.