Is there interest for BLS related test vectors?

[AnomalRoil]

This is more of a discussion than an issue, but I'd like to contribute BLS12-381 and BLS signature test vectors, especially serialization related ones, if there is interest for supporting these "newer" curves and algorithms.
However I don't think these are part of BouncyCastle at all.

Is that a blocker or are you welcoming all test-vectors from all kind of algorithms?

[bleichenbacher-daniel]

I don't know much about the goals and directions of the C2SP project, hence I don't know much about the focus. Anyway, the main criterion for me is whether an algorithm has been described in a rather stable standards-like document.

BouncyCastle support is not necessary for anything. The one nice thing with Java is essentially that the JCE interface allows to write a test once and then run it against multiple providers (of course under the somewhat optimistic assumption that every provider agrees on the interface).

[bleichenbacher-daniel]

I'm currently also looking into pairing friendly curves like BLS12_381.
My focus is the underlying field arithmetic, since that part is frequently implemented individually for each curve. One issue is that the EC groups often have a large cofactor, making it difficult to find edge case points in the group. To get around this it seems to make sense to have separate tests and test vectors for the point multiplication only, assuming that point multiplication can be tested with arbitrary points on the curve, while the primitives based on these curves hopefully do enforce group membership of points.
This should give some decent coverage for the groups G1 and G2. However, so far I don't have a good idea yet how to generate edge cases for the pairing itself.

[AnomalRoil]

@bleichenbacher-daniel that's great news, thanks a lot!
Here are a few thoughts from my implementer side of things:
when working with the target group $\mathbb{G}_T$ of the pairing, it is relatively rare to actually marshal the elements into binary.
We usually have $\mathbb{G}_1$ and $\mathbb{G}_2$ points which get paired together and we compare pairing values together for BLS signatures or we hash the target group elements into some binary blob for identity-based encryption (IBE).

So a difference compared to other algorithms is probably that the marshalling and unmarshalling of the target group elements $\mathbb{G}_T$ is less of a concern (and yeah, that probably makes finding edge cases for it much harder).

The most "dangerous" thing I'd be concerned about when using pairings are subgroup attacks, because with BLS12-381 the groups $\mathbb{G}_1$ and $\mathbb{G}_2$ have small factors.
Subgroup membership tests have been one of the things that has evolved in recent years to become faster. AFAIK, the current state of the art is to rely on M.Scott method.

Thinking about it, BLS12 families of pairing-friendly curves involve operations in the 12th extension of the base field $F_{q^{12}}$, which are slow, therefore implementations instead use its sextic twist (see note on twists by M.Scott) I don't think this should cause extra edge cases.

Another target might be edge cases in the hash-to-curve algorithms, since these are very important for both signatures and IBE.

Finally, there are a few optimisations that could be targets as well for tests:

• aggregation: to verify multiple signatures from different public keys at once, one could be inclined to aggregate them to have a single pairing operation, since aggregation is so easy. I think that if this is not done well, a last signature & last key attack could potentially be done to allow an invalid signature to be cancelled out and go unnoticed, but I'm not aware of any test vectors testing for that. The currently secure method to do that instead is the BDN aggregation scheme.
• multipairing implementations are the norm, in order to perform a single final exponentiation when comparing two pairings (or more), I'm not aware of test vectors looking for edge cases there, nor of any known such edge cases.

[bleichenbacher-daniel]

I've added some test vectors for the arithmetic here:
https://github.com/bleichenbacher-daniel/Rooterberg/tree/main/point_mult
To be able to generate some meaningful edge cases, I'm generating test cases with points in the full group (not just the subgroup). This can of course lead to some difficulties if the library to test only accepts points in the subgroup.

Because of this restriction, it will be necessary to generate additional test vector sets for encoding and actual protocols.

For pairings I still don't have any idea for test vectors that would beat random testing (i.e. start with a random pairing then multiply the inputs with small m and n and the expected result with m*n, and repeat for as long as possible).

Testing so far is somewhat weak. I'm essentially looking for libraries that have unified interfaces so that it is not necessary to write new tests code for each group to test. Encodings is another thing that is somewhat unclear so far I'm using https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-pairing-friendly-curves-11 , but will add other encodings too if I become aware of such encoding.