-
Notifications
You must be signed in to change notification settings - Fork 970
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
Update hash_to_g2 in BLS #1398
Update hash_to_g2 in BLS #1398
Conversation
Signed-off-by: = <=>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you for the interpretation!
The document is for the latest version (draft-irtf-cfrg-hash-to-curve-04
). Perhaps note the IETF version here so that we can keep this doc synced. :)
specs/bls_signature.md
Outdated
|
||
`modular_squareroot(x)` returns a solution `y` to `y**2 % q == x`, and `None` if none exists. If there are two solutions, the one with higher imaginary component is favored; if both solutions have equal imaginary component, the one with higher real component is favored (note that this is equivalent to saying that the single solution with either imaginary component > p/2 or imaginary component zero and real component > p/2 is favored). | ||
* `hash_to_base` - Converting a message from bytes to a field point. The required constant parameters are: Security `k = 128` bits, Field Degree `m = 2` (i.e. Fp2), Length of HKDF `L = 64`, `H = SHA256`, Domain Separation Tag `DST = BLS12381G2-SHA256-SSWU-RO`. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does HKDF-Extract
function take parameter salt
in bytes? Should we note that which encoding format for the DST
value?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yep the salt
for HKDF-Extract
is DST
. The standard has the type of salt
as a string
hence I left it as a string here. However my implementation (and I'm sure others will too) takes bytes so I would not be against also displaying it as bytes.
specs/bls_signature.md
Outdated
return multiply_in_G2((x_coordinate, y_coordinate), G2_cofactor) | ||
x_coordinate += Fq2([1, 0]) # Add 1 and try again | ||
def hash_to_G2(message_hash: Bytes32) -> Tuple[uint384, uint384]: | ||
hash_to_curve(message_hash) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It should be
hash_to_curve(message_hash) | |
P = hash_to_curve(message_hash) |
Can we just rename hash_to_G2
to hash_to_curve
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh I've been spending too much time in rust land I've forgotten my return statements. I think it should be return hash_to_curve(message_hash)
I was very tempted to rename hash_to_g2
however as hash_to_g2
takes Bytes32
whereas hash_to_curve
takes Bytes
I decided to make the abstraction. What are your thoughts on this?
Co-Authored-By: Hsiao-Wei Wang <hwwang156@gmail.com>
Signed-off-by: = <=>
…to kirk-baird-patch-01
The current signature of |
At this point it looks like there will be a wrapper class around the message and domain which will do You can see here for the discussion about the wrapper object. |
Signed-off-by: Kirk Baird <baird.k@outlook.com>
Signed-off-by: Kirk Baird <baird.k@outlook.com>
Signed-off-by: Kirk Baird <baird.k@outlook.com>
This has been updated to version 5 of the hash to curve draft and is ready for review :) Let me know if you want more of less details on any sections. p.s. I haven't made updates based on the bls signatures draft just the hash to curve draft. |
Signed-off-by: Kirk Baird <baird.k@outlook.com>
specs/bls_signature.md
Outdated
* `G2` refers to signatures on G2. | ||
* `SHA256` is the hash function used. | ||
* `SSWU` refers to the Simplified SWU Map from a finite field element to an elliptic curve point. | ||
* `RO` refers to `hash-to-curve` function rather than `encode-to-curve`. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could mention that "RO" stands for "random oracle"
specs/bls_signature.md
Outdated
@@ -33,6 +31,18 @@ The BLS12-381 curve parameters are defined [here](https://z.cash/blog/new-snark- | |||
|
|||
We represent points in the groups G1 and G2 following [zkcrypto/pairing](https://github.com/zkcrypto/pairing/tree/master/src/bls12_381). We denote by `q` the field modulus and by `i` the imaginary unit. | |||
|
|||
## Ciphersuite | |||
|
|||
We use the following Ciphersuite `BLS_SIG_BLS12381G2-SHA256-SSWU-RO_POP_`. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should this ciphersuite only be used for the proof of possession (deposit_data.signature
)?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should the ciphersuite be BLS_SIG_BLS12381G2-SHA256-SSWU-RO-_POP_
(notice the extra -
after RO-
)?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think so, the IETF spec has a hash_to_point
definition for messages of this ciphersuite which is distinct from hash_pubkey_to_point
. My understanding is that if you use the PoP defined by the IETF spec, you should use BLS_SIG_BLS12381G2-SHA256-SSWU-RO-_POP_
or BLS_SIG_BLS12381G2-SHA256-SSWU-RO-_NUL_
if their PoP is not used.
Considering that we do not use the exact PoP defined by the IETF spec, I think we should not claim to use the PoP ciphersuite anywhere.
We use the following Ciphersuite `BLS_SIG_BLS12381G2-SHA256-SSWU-RO_POP_`. | |
We use the following Ciphersuite `BLS_SIG_BLS12381G2-SHA256-SSWU-RO-_NUL_`. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I believe we should just use one ciphersuite for both PoP and regular signature validation.
The extra -
after RO-
is deliberate as that's how the examples were given in the IETF spec.
I agree with Carl, if we don't use the specified PoP we should not use that in our ciphersuite tag. However, I then ask why do we not use that standardized PoP?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The extra - after RO- is deliberate as that's how the examples were given in the IETF spec.
Right :) The extra -
were missing and added them in.
why do we not use that standardized PoP?
What is the difference between the standardized PoP and the currently specified PoP?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good question,
The standardize PoP signs the message:
msg = bytes(public_key)
Where as we sign the message:
msg = signing_root(deposit.data)
Which contains withdrawal_credentials
and amount
along with the public_key
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The standardize PoP signs the message:
msg = bytes(public_key)
Note that there is a specific domain separation tag just for signing pubkeys. (A third tag not mentioned here yet.)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You're right sorry, I didn't notice the tag was slightly different between regular signatures and PoP.
PoP: BLS_POP_BLS12381G2-SHA256-SSWU-RO-_POP_
Regular Signature: BLS_SIG_BLS12381G2-SHA256-SSWU-RO-_POP_
With the option of changing the last _POP_
to _NUL_
if required.
Closed in favour of #1532 |
The purpose of this PR is to update the
hash_to_g2
function to match those specified in the BLS Standards. Riad has kindly already prepared the ciphersuiteBLS12381G2-SHA256-SSWU-RO
. It can be found in section 8.7 of the hash-to-curve standard. I've written a few extra notes in the hopes of assisting anyone implementing it.Things worth noting:
clear_cofactor
is currently being written and when it's complete we should point to that instead of the paper currently being pointed too.Let me know if you would like me to expand into more detail on any parts of
hash_to_curve