Update hash_to_g2 in BLS #1398

kirk-baird · 2019-09-05T05:15:01Z

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 ciphersuite BLS12381G2-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:

The links are currently pointing at the draft of the standard which is changing and hence they will need to be updated once it is finalised.
Pseudo Code for clear_cofactor is currently being written and when it's complete we should point to that instead of the paper currently being pointed too.
The standard states that serialisation should be done the same as Zcash which ours is slightly different.

Let me know if you would like me to expand into more detail on any parts of hash_to_curve

Signed-off-by: = <=>

hwwhww

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

hwwhww · 2019-09-05T06:00:49Z

specs/bls_signature.md


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


Does HKDF-Extract function take parameter salt in bytes? Should we note that which encoding format for the DST value?

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.

hwwhww · 2019-09-05T06:03:39Z

specs/bls_signature.md

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


It should be

Suggested change

hash_to_curve(message_hash)

P = hash_to_curve(message_hash)

Can we just rename hash_to_G2 to hash_to_curve?

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?

specs/bls_signature.md

Co-Authored-By: Hsiao-Wei Wang <hwwang156@gmail.com>

Signed-off-by: = <=>

…to kirk-baird-patch-01

benjaminion · 2019-09-10T21:09:26Z

The current signature of hash_to_G2 is hash_to_G2(message_hash: Bytes32, domain: Bytes8). This draft has hash_to_G2(message_hash: Bytes32). How should we handle the domain parameter?

kirk-baird · 2019-09-10T22:19:43Z

The current signature of hash_to_G2 is hash_to_G2(message_hash: Bytes32, domain: Bytes8). This draft has hash_to_G2(message_hash: Bytes32). How should we handle the domain parameter?

At this point it looks like there will be a wrapper class around the message and domain which will do hash_tree_root and the hash of that wrapper object will be passed to BLS.

You can see here for the discussion about the wrapper object.

specs/bls_signature.md

Signed-off-by: Kirk Baird <baird.k@outlook.com>

kirk-baird · 2019-11-19T03:40:09Z

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.

specs/bls_signature.md

Signed-off-by: Kirk Baird <baird.k@outlook.com>

JustinDrake · 2019-11-26T15:11:04Z

specs/bls_signature.md

+* `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`.


Could mention that "RO" stands for "random oracle"

JustinDrake · 2019-11-26T15:16:37Z

specs/bls_signature.md

@@ -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_`.


Should this ciphersuite only be used for the proof of possession (deposit_data.signature)?

Should the ciphersuite be BLS_SIG_BLS12381G2-SHA256-SSWU-RO-_POP_ (notice the extra - after RO-)?

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.

Suggested change

We use the following Ciphersuite `BLS_SIG_BLS12381G2-SHA256-SSWU-RO_POP_`.

We use the following Ciphersuite `BLS_SIG_BLS12381G2-SHA256-SSWU-RO-_NUL_`.

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?

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?

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.

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

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.

Also revamp ciphersuite breakdown

kirk-baird · 2019-12-19T21:29:11Z

Closed in favour of #1532

Update hash to g2 in BLS readme

6b7d10f

Signed-off-by: = <=>

hwwhww reviewed Sep 5, 2019

View reviewed changes

kirk-baird and others added 3 commits September 5, 2019 20:21

Permalink for reference implementation bls_signature.md

ba63e8b

Co-Authored-By: Hsiao-Wei Wang <hwwang156@gmail.com>

Minor touch ups

ac67b82

Signed-off-by: = <=>

Merge branch 'kirk-baird-patch-01' of github.com:sigp/eth2.0-specs in…

7e66720

…to kirk-baird-patch-01

kirk-baird mentioned this pull request Sep 16, 2019

Kirk baird patch 01 ethereum/py_ecc#79

Merged

benjaminion mentioned this pull request Sep 16, 2019

Implementation of new (draft) hash-to-G2 Consensys/teku#898

Merged

ghost reviewed Sep 24, 2019

View reviewed changes

specs/bls_signature.md Outdated Show resolved Hide resolved

Minor typo

cfe7f31

Signed-off-by: Kirk Baird <baird.k@outlook.com>

hwwhww added the scope:BLS label Nov 10, 2019

kirk-baird added 2 commits November 19, 2019 14:28

Update spec to match version 5 of the hash to curve standard

4dfb033

Signed-off-by: Kirk Baird <baird.k@outlook.com>

Fix indent and warning

706fd52

Signed-off-by: Kirk Baird <baird.k@outlook.com>

kirk-baird changed the title ~~[WIP] Update hash_to_g2 in BLS~~ Update hash_to_g2 in BLS Nov 19, 2019

MrChico reviewed Nov 22, 2019

View reviewed changes

specs/bls_signature.md Outdated Show resolved Hide resolved

Add TOC for ciphersuite

b444cc0

Signed-off-by: Kirk Baird <baird.k@outlook.com>

JustinDrake reviewed Nov 26, 2019

View reviewed changes

JustinDrake added 7 commits November 26, 2019 15:57

Fix ciphersuite typo

19c67ec

Also revamp ciphersuite breakdown

Update bls_signature.md

ce16f37

Update bls_signature.md

d3a9583

Update bls_signature.md

b6fa1cb

Update bls_signature.md

edb9bfc

Update bls_signature.md

6b14553

Update bls_signature.md

7f71659

CarlBeek mentioned this pull request Dec 2, 2019

BLS Specs rewrite for IETF clarity #1499

Closed

CarlBeek mentioned this pull request Dec 17, 2019

Yet another attempt at adopting IETF BLS Standards #1532

Merged

kirk-baird closed this Dec 19, 2019

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Update hash_to_g2 in BLS #1398

Update hash_to_g2 in BLS #1398

kirk-baird commented Sep 5, 2019

hwwhww left a comment

hwwhww Sep 5, 2019

kirk-baird Sep 5, 2019

hwwhww Sep 5, 2019 •

edited

Loading

kirk-baird Sep 5, 2019

benjaminion commented Sep 10, 2019

kirk-baird commented Sep 10, 2019

kirk-baird commented Nov 19, 2019

JustinDrake Nov 26, 2019

JustinDrake Nov 26, 2019

JustinDrake Nov 26, 2019

CarlBeek Nov 26, 2019 •

edited

Loading

kirk-baird Nov 26, 2019

JustinDrake Nov 26, 2019

kirk-baird Nov 26, 2019

CarlBeek Nov 27, 2019 •

edited

Loading

kirk-baird Nov 28, 2019

kirk-baird commented Dec 19, 2019


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

	We use the following Ciphersuite `BLS_SIG_BLS12381G2-SHA256-SSWU-RO_POP_`.
	We use the following Ciphersuite `BLS_SIG_BLS12381G2-SHA256-SSWU-RO-_NUL_`.

Update hash_to_g2 in BLS #1398

Update hash_to_g2 in BLS #1398

Conversation

kirk-baird commented Sep 5, 2019

hwwhww left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

hwwhww Sep 5, 2019 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

benjaminion commented Sep 10, 2019

kirk-baird commented Sep 10, 2019

kirk-baird commented Nov 19, 2019

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

CarlBeek Nov 26, 2019 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

CarlBeek Nov 27, 2019 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

kirk-baird commented Dec 19, 2019

hwwhww Sep 5, 2019 •

edited

Loading

CarlBeek Nov 26, 2019 •

edited

Loading

CarlBeek Nov 27, 2019 •

edited

Loading