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
It could be very helpful IMO to define interfaces (via abstraction/inheritance or CRTPs, cc: @madars) to make the code related to field arithmetic generic (same would apply to groups btw). As such, I think that exposing the degree of field extensions in this interface - say via a static method - would be helpful to manipulate the elements.
An immediate example that comes to mind is for custom serialization of elements of G2 in a pairing group. Different pairing groups will have different embedding degrees and twist degrees, which will result in different degrees for the extension fields over which elements of G2 will be defined. Having access to the field extension degree through the G2 elements' coordinates would allow to implement generic "custom" serialization functions, and would allow, more broadly to navigate the the field tower ("from top to bottom") which can be useful.
Note that, another approach to expose the field extension degree is to refactor the way polynomial coefficients are handled (see here for instance: https://github.com/scipr-lab/libff/blob/master/libff/algebra/fields/fp3.hpp#L50). In fact, switching from individual attributes for each coefficient to using a single container attribute to store all the polynomial coefficients would expose the degree of the extension via the size() method of the coefficients container.
It could be very helpful IMO to define interfaces (via abstraction/inheritance or CRTPs, cc: @madars) to make the code related to field arithmetic generic (same would apply to groups btw). As such, I think that exposing the degree of field extensions in this interface - say via a static method - would be helpful to manipulate the elements.
The degree is not exposed as far as I can tell, and the value is hardcoded in various places, see: https://github.com/scipr-lab/libff/blob/master/libff/algebra/fields/fp2.hpp#L78 for instance (i.e. the
2
factor is the degree of the ext. field here)An immediate example that comes to mind is for custom serialization of elements of G2 in a pairing group. Different pairing groups will have different embedding degrees and twist degrees, which will result in different degrees for the extension fields over which elements of G2 will be defined. Having access to the field extension degree through the G2 elements' coordinates would allow to implement generic "custom" serialization functions, and would allow, more broadly to navigate the the field tower ("from top to bottom") which can be useful.
[EDIT]: I just saw that a static method
extension_degree
was part of some extension field implementations (see: https://github.com/scipr-lab/libff/blob/master/libff/algebra/fields/fp12_2over3over2.hpp#L82 for instance), but not part of other extension field implementations (e.g https://github.com/scipr-lab/libff/blob/master/libff/algebra/fields/fp3.hpp). This is inconsistent, and should then be fixed IMO. As such, and to my point above, we may want to distinguish between the "extension_degree", say 6 in F_{p^6}, and the "tower_extension_degree", say 2 in F_{p^{2^3}}.The text was updated successfully, but these errors were encountered: