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
Section 4.2 of the BLS paper outlines how to use the x-coordinate of the "signature point" as the signature itself. It requires reconstructing the point during validation, and then an additional pairing check.
The text was updated successfully, but these errors were encountered:
The BLS12-381 implementation of the pairing library already allows for short signatures (of the same size as the x-coordinate only) by using G1Compressed.
It takes advantage of unused bits to be able to uniquely reconstruct the point.
Unsetting the three most significant bits, would yield the x-coordinate only (although I currently don't see any advantage except maybe compatibility with other implementations).
Wouldn't it be best to implement short signatures on BLS12-381 using this compressed encoding?
You'd never use BLS merely for the length. You'd choose curve roles based on your aggregation plans, so you need a reversable Engine trait that hides the base fields, which I did in https://github.com/w3f/bls As a rule though, everyone defaults to 48 byte public keys and 96 byte signatures though because mostly people want BLS for voting in consensus protocols with far more signers than simultaneous messages.
Oops I miss-read your response. Yes this issue could likely be closed.
Section 4.2 of the BLS paper outlines how to use the x-coordinate of the "signature point" as the signature itself. It requires reconstructing the point during validation, and then an additional pairing check.
The text was updated successfully, but these errors were encountered: