Closed xrchz closed 3 months ago
fwiw the same result occurs if I use the hexToBytes
function from the Chainsafe repository
function hexToBytes(hex) {
if (hex.startsWith("0x")) {
hex = hex.slice(2);
}
if (hex.length & 1) {
throw Error("hexToBytes:length must be even " + hex.length);
}
const n = hex.length / 2;
const a = new Uint8Array(n);
for (let i = 0; i < n; i++) {
a[i] = parseInt(hex.slice(i * 2, i * 2 + 2), 16);
}
return a;
}
Ethereum uses the following
The IETF BLS signature draft standard v4 with ciphersuite BLS_SIG_BLS12381G2_XMD:SHA-256_SSWU_ROPOP
Maybe the hash to curve algorithm is different in noble?
I haven't had luck using BLS_SIG_BLS12381G2_XMD:SHA-256_SSWU_RO_POP_
as the DST option to noble's functions yet. But probably there's some other configuration needed?
They are compatible. Proof: https://github.com/paulmillr/bls12-381-keygen, readme example generates same keys.
For verification you need to specify DST or encodeDST correctly.
So my claim is simply that the default configuration does not verify Ethereum signatures. I see now that the reason is the DST for Ethereum beacon chain differs from the noble curves default DST. My suggestion is to add this to the README and possibly include an example of using the Ethereum DST correctly.
The link you provided is about key generation, which is not precisely relevant to signature generation and verification.
I don’t know which DST is correct for eth. If you would like to clarify usage with eth, you can test it and add proper example to readme with pull request
Thank you so much for your help. I created this https://github.com/paulmillr/noble-curves/pull/129.
1.4.0 is out
outputs
using
Given that both are purporting to use BLS12-381, and the Chainsafe version is actually used on Ethereum, I suggest that the Noble version at least have a warning that the default configuration is not compatible with Ethereum (if indeed there is not a more nefarious bug).