bls_12_381 CURVE.G2.fromBytes mutates input about noble-curves

[paulmillr]

const Fp12 = bls.fields.Fp12;
const left = pairing(left1, left2, false)
const right = pairing(right1, right2, false)
Fp12.finalExponentiate(left, right)

[paulmillr]

Right...will think of something. Don't worry, there will be an api for this

[paulmillr]

You shouldn't use CURVE.G2.fromBytes, this is internal. Use G2.fromHex instead.

I will need to hide the internal methods to prevent misuse.

[paulmillr]

Done

[blazmrakgid]

Well... fuck me, I shot myself in the head with this one :D functions on the CURVE can be super useful for doing curve operations yourelf, because they have stuff like finalExponentiation on Fp12, fromBytes, etc. I implemented BBS+ and had to resort to them in a couple of places. Please leave it public, just disclaim that when using CURVE, you are on your own.

[paulmillr]

@blazmrakgid which functions? Fp, Fp2, Fp12, G1, G2 are available in top-level namespace. There is no need to write CURVE.G2 when you can just write G2.

[blazmrakgid]

There are some functions only on curve (Fp12.finalExponentiate for example). Looking at it, it might be the only one that I need... I got confused by fromHex, because I would expect a hex string to go in, but it takes both hex string and bytes 🤷

I don't know all the use cases, but it might be worth creating the API with utils.pair([left1, left2], [right1, right2]) that does the e(G1, G2) = e(G1, G2).

Oh, I almost forgot: thanks for the library and blog, helped me a lot in understanding ECC and creating stuff with BLS 👏

[paulmillr]

bls.pairing function has optional third argument withFinalExponent: boolean = true.

Would it solve your use case?

See

noble-curves/src/abstract/bls.ts

Lines 236 to 245 in fe380da

	function pairing(Q: G1, P: G2, withFinalExponent: boolean = true): Fp12 {
	if (Q.equals(G1.ProjectivePoint.ZERO) || P.equals(G2.ProjectivePoint.ZERO))
	throw new Error('pairing is not available for ZERO point');
	Q.assertValidity();
	P.assertValidity();
	// Performance: 9ms for millerLoop and ~14ms for exp.
	const Qa = Q.toAffine();
	const looped = millerLoop(pairingPrecomputes(P), [Qa.x, Qa.y]);
	return withFinalExponent ? Fp12.finalExponentiate(looped) : looped;
	}

[blazmrakgid]

Yes, that would be one solution, but I think it is slower doing it twice (once for each side)? Anyway, your work has got me really far, and not exposing the CURVE makes sense for the API. If I want performance I'll have to fork it anyways.

[paulmillr]

Yes, that would be one solution, but I think it is slower doing it twice (once for each side)?

No, the speed should be the same.

In fact many algorithms do exactly this: they execute non-final-exp part for everything and then execute final exp just once for all

[blazmrakgid]

Then I misunderstood how you meant me to use it. What I mean is this:

const left = pairing(left1, left2, true)
const right = pairing(right1, right2, true)

left == right

meaning final-exp runs twice. Am I missing something?

[paulmillr]

just use false, not true.

[blazmrakgid]

We have gone full circle now 😄 If I use false, then i need Fp12.finalExponentiate(), which is only available on the CURVE.Fp12 😄

[paulmillr]

const left = pairing(left1, left2, false)
const right = pairing(right1, right2, false)
pairing(left, right, true)

[blazmrakgid]

But pairing takes G1 and G2, not Fp12, which is the result of pairing(...)?