Different results against zcash's implementation

[kobigurk]

Hi team,

I'm working on a naive implementation of pairings to generate some test vectors and noticed my results were different than Zcash's implementation, though my results were the same as your python implementation.

Specifically, I tested the on the G1 and G2 generators and checked against the results here: https://github.com/zkcrypto/pairing/blob/master/src/bls12_381/tests/mod.rs.

Did you notice the difference? Am I doing something silly?

[nmarley]

The Chia spec is actually different than the Zcash one. It's been tweaked a bit and G1/G2 swapped for sigs and pubkeys. There is a Go port of the Zcash implementation here: https://github.com/phoreproject/bls

(Note: I'm not on this team, just kinda familiar w/these libs.)

[kobigurk]

Hey @nmarley,

Thanks for the reply. I'm not sure it addresses exactly the question though, since I'm looking at the step even before the BLS signatures part :) Just the pairings on BLS12-381.

[nmarley]

Ah, ok. Thanks for the clarification. I noticed this discrepancy too in my own implementation, but since the "vectors sent from Diego Aranha" weren't really part of any existing test vectors (seems like they were sent offline and just coded into the tests), I just assumed they might be wrong (I do realize he's the author of RELIC) or there was no good way to test them. At the same time, most of the low-level stuff here is actually using RELIC so it's a head-scratcher for me. I wish there was some existing test vector / spec for this.

[kobigurk]

Hm, that's a good point - I'll try to run the same calculation with the RELIC version.

EDIT: seems kind of difficult. @nmarley do you a handy way to do it?

[mariano54]

The bls381 pairing in the python implementation should be identical to relic. The test vectors specified in the library are for signature verification, instead of the raw pairing operation, but you can see that they are the same. I have not compared against the vectors in the zcash library.

[kobigurk]

Thanks @mariano54! Could you point me to the best test to look at? I guess something from here: https://github.com/Chia-Network/bls-signatures/blob/master/src/test.cpp?

[mariano54]

Anywhere that signatures are being verified, it's where a pairing operation happens: https://github.com/Chia-Network/bls-signatures/blob/master/src/test.cpp#L80

This calls pc_map_sim from relic. (It's actually a multi pairing, one for each public key, which saves time in the final exponentiation).

https://github.com/Chia-Network/bls-signatures/blob/master/src/signature.cpp#L84

[kobigurk]

@mariano54, ah, I saw that. I'm pretty sure that won't give me the answer - since it's a multi-pairing that you equate to 1. This doesn't rely on a specific result of a pairing, only that the pairings cancel each other.

So even if the pairings give different results between RELIC and other implementations, given that they're both bilinear, the result will be 1.

EDIT: Any check that has pairing equations probably won't suffice, unless it's equated to some fixed test vector.

[janus]

@nmarley Do you know where I can get JavaScript port of BLS-12_381. Not a wrapper, I want to generate keys on browser

[dfaranha]

Hi! I randomly stumbled upon this.

Assuming the issue is not solved, this week I had to help students debug a BLS12-381 implementation that they are building and had another chance to cross-check the test vectors in RELIC with the ZCash codebase. Both of the libraries agree and test vectors for e(g1,g2) for generators of G1,G2 are indeed correct.

[mariano54]

That is great to hear, thanks Diego!

[dfaranha]

Perhaps I was not clear: the test vectors in RELIC/ZCash are correct. I could not find raw test vectors for pairings in Chia to cross-check, but I suspect the issue discussed here might be a common corner case I found in other implementations.

The BLS12-381 curve parameter is negative, so technically you need to invert the result of the Miller loop before the final exponentiation, which is just a cheap conjugation in Fp^12. Not inverting it still gives a bilinear map, so it's not a big deal unless for interoperability (and strict adherence to the mathematical definition).

[github-actions[bot]]

'This issue has been flagged as stale as there has been no activity on it in 14 days. If this issue is still affecting you and in need of review, please update it to keep it open.'

[github-actions[bot]]

'This issue was automatically closed because it has been flagged as stale and subsequently passed 7 days with no further activity.'