The same Domain is used for both G1 and G2 Hash()

[AnomalRoil]

It appears that we are currently re-using the same domain for both G1 and G2 hash to curve functions:

kyber-bls12381/kyber_g1.go

Lines 135 to 140 in 21249c0

	func (k *KyberG1) Hash(m []byte) kyber.Point {
	p, _ := bls12381.NewG1().HashToCurve(m, Domain)
	k.p = p
	return k
	}

kyber-bls12381/kyber_g2.go

Lines 140 to 144 in 21249c0

	func (k *KyberG2) Hash(m []byte) kyber.Point {
	pg2, _ := bls12381.NewG2().HashToCurve(m, Domain)
	k.p = pg2
	return k
	}

with Domain being:

kyber-bls12381/kyber_g2.go

Lines 14 to 16 in 21249c0

	// Domain comes from the ciphersuite used by the RFC of this name compatible
	// with the paired library > v18
	var Domain = []byte("BLS_SIG_BLS12381G2_XMD:SHA-256_SSWU_RO_NUL_")

This is unfortunate as it makes us non-spec compliant 😢
Security-wise it shouldn't be an issue as long as we are not re-using the same secret on both G1 and G2.

[webmaster128]

This was unnoticed in drand-verify which is used to verify the new g1g2 swapped mainnet beacons in production. The same bug is implemented there, making it compatible to the bug.

[webmaster128]

Would it be a viable migration path to make this domain configurable in this library, spawn a new drand mainnet with the fix and shut down the G1/G2 swapped one at some point? That would allow all new users to have a bug free environment, restore the elegance and allow a smooth transition from classic mainnet and the buggy mainnet.

[AnomalRoil]

This was solved in #23 and the latest release is now compatible with the proper DST.

For the rest of the drand stack, a new scheme is being introduced that's RFC conformant in drand/drand#1249

and we'll be launching a new network meant for long term support and sunsetting the old G1 3s one (e.g. shutting it down after announcing its shutdown in a couple months, expect a blog post on drand.love about it later this week)