-
Notifications
You must be signed in to change notification settings - Fork 173
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Get access to the Fp12
representation from Gt
#96
Comments
What functionality do you need? I'm generally reluctant to expose the underlying |
The only thing we need is that we can serialize the value in a specific way. // coefficients in the extension F_6
let c0_6 = self.c0;
let c1_6 = self.c1;
let coeffs = [
// coefficients of c1_6 in the extension F_2
c1_6.c2, c1_6.c1, c1_6.c0, // coefficients of c0_6 in the extension F_2
c0_6.c2, c0_6.c1, c0_6.c0,
];
for p in coeffs.iter() {
let repr_c1 = FqRepr::from(p.c1);
let repr_c0 = FqRepr::from(p.c0);
for d in repr_c1.as_ref().iter() {
d.serial(out);
}
for d in repr_c0.as_ref().iter() {
d.serial(out);
}
}
} We could actually work around this and shuffle some other things around I think so we maybe wouldn't have to do this, but we cannot change the protocol we have now without massive migration pain, so we have to stick with the exact format we have at the moment. |
I do sympathize with wanting to have as type-safe API as possible :) |
Is there any way to make progress on this? I'm running into the same problem while trying to implement an IBE scheme where we need to hash elements of Gt; any (stable over time) serialization would be fine, no deserialization required. |
@str4d is there any way to make progress on this? Would you accept a PR where this was exposed conditionally based on a feature that is off by default and documented as unstable/unsafe? |
The https://docs.rs/bls12_381/0.7.0/bls12_381/struct.Gt.html has very little functionality exposed at the moment.
It implements the Group trait and a few helpers, however this is not enough for one of the ZK protocols we have.
What would suffice for us is a way to get the underlying
Fp12
representation ofGt
. For example,would be perfectly adequate, or any other alternative you would prefer.
Is this something you are open to adding to the library? Without this we cannot upgrade from the old
pairing
crate that embedded the bls implementation to the recent one.This is related to #10 although I need less than that.
The text was updated successfully, but these errors were encountered: