Compatibility with other bls12-381 libraries

[iancoleman]

Compatibility between bls12-381 libraries might be useful. For example, etherum2, zcash, chia.net, algorand, dfinity are all using or plan to use bls12-381.

There's a simple single-key signature verification in this test which does not pass with threshold_crypto. The secret key can be imported to threshold_crypto and it gives the same public key as in the test, but the signature does not verify.

skbytes = [74,53,59,227,218,192,145,160,167,230,64,98,3,114,245,225,226,228,64,23,23,193,231,156,172,111,251,168,246,144,86,4]
pkbytes = [133,105,95,203,192,108,196,196,201,69,31,77,206,33,203,248,222,62,90,19,191,72,244,76,219,177,142,32,56,186,123,139,177,99,45,121,17,239,30,46,8,116,155,221,191,22,83,82]
msgbytes = [7,8,9]
sigbytes = [184,250,166,214,163,136,28,159,219,173,128,59,23,13,112,202,92,191,30,107,165,165,134,38,45,243,104,199,90,205,29,31,250,58,182,238,33,199,31,132,68,148,101,152,120,245,235,35,12,149,141,213,118,176,139,133,100,170,210,238,9,146,232,90,30,86,95,41,156,213,58,40,93,231,41,147,127,112,220,23,106,31,1,67,33,41,187,43,148,211,213,3,31,128,101,161]

However the test signature does verify with

javascript noble-bls12-381

c++ chia-network/bls-signatures

c supranational/blst

Is there a chance that threshold_crypto will be compatible with these other bls12-381 libraries? Or am I missing something particular about the way those libraries differ from this one?

A few notes:

These libraries all seem to be using sha2_256 (see this discussion) but threshold_crypto is using sha3_256 (see utils.rs). I tried changing threshold_crypto to sha2 but that change alone did not lead to the test passing.

All these libraries have a DST parameter set to "BLS_SIG_BLS12381G2_XMD:SHA-256_SSWU_RO_NUL_" but I can't see any reference to this in threshold_crypto nor in any bls12-381 specs or docs, eg IETF and hackmd.io. So I'm definitely out of my depth and am hoping with this issue to understand whether threshold_crypto will aim to be compatible with the broader cryptocurrency bls12-381 implementations or not.

I realize this is more of a support request than a bug or feature request, but I feel there's some small potential that this may lead to a change in this library so I figured better to raise it and learn something than leave it and never understand it.

[iancoleman]

Recording some of my reading on this topic for my own future reference

https://mattrglobal.github.io/bbs-signatures-spec/

DST is an acronym for Domain Separation Tag

See Hashing to Elliptic Curves
2.2.5. Domain separation
https://tools.ietf.org/html/draft-irtf-cfrg-hash-to-curve-08#section-2.2.5
and
3.1. Domain separation requirements
https://tools.ietf.org/html/draft-irtf-cfrg-hash-to-curve-08#section-3.1

Applications that instantiate multiple, independent instances of
either hash_to_curve or encode_to_curve MUST enforce domain
separation between those instances. This requirement applies both in
the case of multiple instances targeting the same curve and in the
case of multiple instances targeting different curves. (This is
because the internal hash_to_field primitive (Section 5) requires
domain separation to guarantee independent outputs.)

I'm not sure yet how relevant this reading is to this issue, or the relevance of the overall issue to poanetwork/threshold_crypto, so would be glad for any other input.

[afck]

I agree it would be good to make it compatible. Not sure if anyone is working on this repository right now, though.

[dan-da]

+1 for interop.