tests: add tests for newly introduced primitives

[tshakalekholoane]

Is your feature request related to a problem? Please describe.

The ECRYPT-CSA report specified additional primitives (see commits below) that aren't mentioned in all the other standards and thus do not have corresponding tests in these modules.

Commits:

• cc5919d.
• df0888b.
• 509a212.
• 7381f9a.

Describe the solution you'd like

Write tests for these.

Describe alternatives you've considered

Leave it as is. The return value is the same in all of them given they'll be assessed against an exception list that already specifies primitives that the standard explicitly mentions so the value add seems minimal. Nonetheless it might be a good thing to have.

[ndcroos]

Hi, I am interested in this, but I am not sure how tests for these should look like, or how to go about this task. Can you elaborate on that, or give an example?

[tshakalekholoane]

Hi. Thank you for your interest.

To give an overview, the core crate has primitive instances that are supposed to represent their real-world equivalents. So when one scans a TLS certificate or SSH key using the cmd/wardstone crate, it parses that key and creates these internal representations from that information.

These primitive representations are then what gets passed in individually to functions that assess their compliance. For example, something like the test id_ecdsa_256_wardstone.pub public key would be translated into the NIST P-256 elliptic curve key representation and that would then get passed into the validate_ecc function of any type that implements the Standard trait.

(The types that implement this trait in this crate are all in the crates/core/src/standard directory).

But now the issue is some of these standards were implemented before we had an "exhaustive" list of primitives. Therefore, some unit tests do not capture these newer primitives. For example, the is no unit test in the NIST standard that assesses the BLAKE3 hash function.

So in order to improve the test coverage, this would require going through all the standards test modules in the crate, finding primitive instances that do not have test cases, and then writing tests for those using macros that are aimed at simplifying this task just as I showed above.

At this point I'd expect the logic to be solid enough that anyone working on this issue wouldn't need to verify the result against the relevant publication. So it's largely just a matter of manually going through the test modules and writing tests for primitives that are not captured.

Does that help?