bls test vectors

[curiecrypt]

Test vectors for bls12-381, still under construction!

[lehins]

What's going on? Why are we getting PRs with Rust?

[iquerejeta]

So this is for the test vectors. We were thinking the other day with @tdammers were should the script that creates test vectors for BLS12-381 bindings live. The conclusion was that the best place for that code to live was in the repo where the test-vectors lived, hence cardano-base. However, this is obviously open to discussion if you think it should be outside of the repo.

The motivation to put it here is that we could include a test in the CI that checks that the file used for the test vectors is equal to what is generated by the rust script. However, the idea is that we don't put any dependencies on the haskell build with rust. i.e., the rust script only needs to be run by the CI or anyone wanting to re-generate the test vectors.

WDYT?

[lehins]

This is a Haskell project. Even tests need to be written in Haskell, not Rust.

In this case looks like the goal is to compare that the functionality matches another implementation.
I would prefer to avoid adding other languages and libraries if they can be avoided. We already depend on libblst, then why not implement generation of the test vectors in C?

FYI. I don't have anything against Rust, I think it is a great language. But, I do have a problem with addition of unnecessary dependencies! Addition of a new technology increases complexity of a repository significantly.

[iquerejeta]

I understand. The reason why we decided to do the test vectors in rust was to compare the library we use (blst) with zkcrypto's library of the same curve, which is a library used in production. Creating the test vectors in C or Haskell would require bindings, and we'd depending on the rust library regardless, so IMO it doesn't really make sense.

I understand wanting to leave rust outside of the build CI, in which case we can upload the rust code in another repo, link to that in the README and only have here the test vectors.

If that's your preferred path, we'll go that way 👌

[lehins]

Creating the test vectors in C or Haskell would require bindings

I don't understand why would we need any sort of bindings if we wanted to write a C program that generates test vectors. I would expect it to be same as the rust program in this PR, which depends on Rust implementation of bls, except that program would be written in C and depend on then C implementation bls

I understand wanting to leave rust outside of the build CI, in which case we can upload the rust code in another repo, link to that in the README and only have here the test vectors.

If you think what I am suggesting is too hard to do then we don't need to waste any time and I am not gonna stand in way of having this code in this repo. After all, it will only be used once to generate the test vectors. If we had to run it on CI and locally every time we had to run the test suite that would be a different story and I would be pushing back much harder against it.

[iquerejeta]

that program would be written in C and depend on then C implementation bls

But we want to create these test vectors with the rust library, which is the 'other' reference implementation of bls12-381. We could do it with the underlying library, but the goal of these test vectors is that they are independently generated.

If we had to run it on CI [...] I would be pushing back much harder against it.

Then we should discuss this :) my intention was to include a check in CI that the test-vectors file used for tests corresponds to the output of the rust binary. If we don't include such a check in the CI, then I don't see the purpose of including it in the repo, and we can leave it out.

[lehins]

my intention was to include a check in CI that the test-vectors file used for tests corresponds to the output of the rust binary

The output of the Rust program will be checked-in in this repo, no? Then why do we need to run Rust on CI?

But we want to create these test vectors with the rust library, which is the 'other' reference implementation of bls12-381. We could do it with the underlying library, but the goal of these test vectors is that they are independently generated.

Which library are you trying to test? Are you trying to test the libblst library implementation or do you want to test the Haskell binding to liblst that we provide in cardano-crypto-class library? If it is the latter, then there is nothing wrong with using the same C library to generate test vectors. However, if it is the former and you want to test that Rust implementation matches the C implementation, then such test suite has no business being being in this repository as it is unrelated to our Haskell bindings in any way. A test like this would belong in either the Rust library or in the C library repository.

My understanding was that the reason for writing this script in Rust was only because it is easier to write Rust, rather than C.

[iquerejeta]

The output of the Rust program will be checked-in in this repo, no? Then why do we need to run Rust on CI?

Apart from checking the output of the Rust program, I was thinking of checking that the test vectors we use are indeed the output of the rust program. Like this we guarantee that the Rust script and the test vectors do not go out of sync.

Are you trying to test the libblst library implementation?

Yes, the intention is to have tests for the libblst library, as the latter does not contain an extensive test-suite. That's what motivated a different choice of the underlying library. I agree that such tests should not be in the bindings library, but given that we include test vectors in our repo, we might as well have them generated from a different library, and so we kill two birds with one stone.

[iquerejeta]

Left a few comments. Some of the are generic that can be applied in several spots of the script (e.g. the usage of projective point, or the usage of a helper function). Two final comments:

• I'd suggest we put the data files in a different folder
• We now have bls12-381-test-vectors that only contains test-vectors-bls12_381. I'd suggest we put the contents of test-vectors-bls12_381 directly in the first folder.

[curiecrypt]

LGTM

[lehins]

@iquerejeta This PR is up your alley. We've already talked about this work, so if you can oversee this work further that'll be great.

I suspect Haskell tests will be added in a separate PR, right?

[iquerejeta]

Haskell tests will be added in a separate PR, yes. I will oversee the PR. If you could approve it to unblock your change request, so that once I approve we can merge.

[lehins]

👍

[iquerejeta]

Looks good. Some minor suggestions before merging.