Skip to content
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

BLS: ZCash-style curve point encodings? #21

Closed
nomeata opened this issue Sep 27, 2020 · 7 comments
Closed

BLS: ZCash-style curve point encodings? #21

nomeata opened this issue Sep 27, 2020 · 7 comments

Comments

@nomeata
Copy link

nomeata commented Sep 27, 2020

I noticed that miracl encodes BLS public keys and signatures using the SEC-style compressed format (leading 0x02 or 0x03 depending on parity of y coordinate, followed by x coordinate). The RFC draft for BLS, however, suggests a different encoding, using the spare top 3 bits of the 48/96 bytes, according to the scheme described at https://github.com/zkcrypto/bls12_381/blob/bc1706f6426aca52b9a99e5f100bdb7d119305d3/src/notes/serialization.rs.

Do you have plans to support that encoding in miracl, too?

@mcarrickscott
Copy link
Contributor

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.

@nomeata
Copy link
Author

nomeata commented Sep 28, 2020

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

@nomeata
Copy link
Author

nomeata commented Sep 28, 2020

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.

@mcarrickscott
Copy link
Contributor

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

@nomeata
Copy link
Author

nomeata commented Sep 28, 2020

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)

@mcarrickscott
Copy link
Contributor

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..

@mcarrickscott
Copy link
Contributor

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..

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants