I think tests that compare multiple implementations using a mixture of constructed static vectors and random test cases are obviously a best practice everyone should engage with, even if the other implementation isn’t something that you’d expect anyone to use in production.
Currently the the tests have comparison tests w/ openssl. It used to be particularly important to test against openssl because it was important to Bitcoin consensus. An analogous test today would be embedding an old version of libsecp256k1 (yo dawg) but I don’t think the library has changed enough to justify that today. If ever someone writes whole new field or scalar implementations that might be a good idea, however.
OpenSSL has been at least a minor burden: Its API changes from time to time which breaks the builds, and users can’t be counted on to have the development headers (and making them install them for a comparison test seems silly)– so these important tests have to be optional.
Instead, the library source could include a stripped down copy of micro-ecc ( https://github.com/kmackay/micro-ecc ), which is a small, essentially single file library that supports several curves, ecdh and ecdsa. It is at least as portable as libsecp256k1 itself, and under a compatible license. I don’t have a particularly high opinion of micro-ecc (on review I found some serious constant-timness bugs and didn’t find any evidence of particularly good testing practices, though it does have some testing, which –sadly– is much better than most crypto code found on the net, including stuff widely promoted as high quality)… but its implementation is pretty distinct from libsecp256k1 so there is a chance that many flaws would be uncorrelated.
It would also be fairly easy to add BIP340 schnorr support to micro-ecc and doing so would likely be of value to the public because while I wouldn’t recommend micro-ecc to people generally, it does support 8-bit microcontrollers which this library has no intention of supporting. For similar reasons the additional testing of micro-ecc as a side-effect of being harnessed to libsecp would likely be a public good. Ideally if someone did write schnorr support for it it should be someone who didn’t work on this library or bip-340 to reduce correlation.
