BLS: ZCash-style curve point encodings? about core HOT 7 CLOSED

ZCash encoding is now available as an option, if and only if the modulus has 3 spare bits available in its most significant byte. So a 381-bit modulus has 3 spare bits, whereas a 383 bit modulus has only one. To activate, manually set ALLOW_ALT_COMPRESS to true. This flag may be found in the config_curve.* file, or in ecp.*

G2 coordinate component ordering has been switched in all cases.

Probably needs a bit more testing..

from core.

If each curve gets its own bespoke compression format, then we are heading for chaos. And just to save one byte! And the determination of sign is here based on the MSB of y, whereas using the LSB (Least Significant Bit) is more common. Indeed the Hash-To-Curve draft standard just removed MSB as an option, and here it is back again! And for y_1=a+ib and y_2=c+id \in F_{p^2} which is "lexicographically largest"? Not immediately clear to me.

Having said that it will not be hard to do. IF the curve has 3 spare bits and IF MSB sign is selected (BIG_ENDIAN_SIGN), then we can offer it as an option.

from core.

As a poor minion who has to deal with whatever the spec says (and other implementations produce) would certainly appreciate that :-)

from core.

Is it actually the MSB? Since p isn’t a power of two, aren’t there possible y coordinates (close to the middle of the range) that are negations of each other, but where the MSB is both 0? Maybe that’s the reason why they refer to a (lexicographic) order instead.

from core.

Yes, you are right. I was using MSB rather loosely..

from core.

Oh, and just before someone else stumbled over this: The ZCash encoding also encodes the components of a G2 point in the other order (first b then a)

from core.

Yes, just noticed that. Strange and rather non-intuitive (to me anyway). But there are no standards for this as far as I am aware, so I am happy to go along..

from core.