Default bls12_381 is incompatible with Ethereum beacon chain about noble-curves

[xrchz]

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;
}

[xrchz]

Ethereum uses the following

The IETF BLS signature draft standard v4 with ciphersuite BLS_SIG_BLS12381G2_XMD:SHA-256_SSWU_RO_POP_

Maybe the hash to curve algorithm is different in noble?

[xrchz]

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?

[paulmillr]

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.

[xrchz]

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.

[paulmillr]

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

[xrchz]

Thank you so much for your help. I created this #129.

[paulmillr]

1.4.0 is out