cisco / libacvp

The libacvp library is a client-side implementation of the draft ACVP protocol (github.com/usnistgov/ACVP).
Apache License 2.0
67 stars 69 forks source link

Fix some issues and capabilities #802

Closed 0140454 closed 11 months ago

0140454 commented 11 months ago

Output outLen for SHAKE-128 and SHAKE-256 test vectors

For SHAKE-128 and SHAKE-256, we should output outLen.

Reference

Output required fields for RSA KeyGen if randPQ B.3.6 used

For RSA KeyGen with randPQ B.3.6, xP, xP1, xP2 and other fields should be outputed.

Reference

Add hash algorithms for KAS-ECC-SSC and KAS-IFC-SSC

Register allowed hash functions.

Reference - KAS-IFC-SSC Reference - KAS-ECC-SSC

Fix hashZ related functions for KAS-ECC-SSC and KAS-IFC-SSC

Given hashFunctionZ in test group, handle related functions correctly.

Fix "!predResistanceEnabled and reseedImplemented" for DRBG

Reseed the DRBG before first generation.

Reference

Update defines for KDA

Max z bit is 65536.

Reference

Support FIPS 186-5 for RSA SigGen

Add allowed hash function for RSA SigGen.

Reference

abkarcher commented 11 months ago

Hello,

Thank you for the work! Unfortunately, I am not able to accept this PR at this time for a few reasons.

We cannot accept arbitrary changes to the algorithm registration in app_main, as it is supposed to match OpenSSL's awarded algorithm certificates. KAS-IFC and ECC specifically do not test with hash algorithms because the certs do not.

Additionally, regarding acvp_digest, the library side of libacvp should not have any dependencies on OpenSSL, or perform any crypto operations itself. Hash support is typically used for modules that do not allow output of plain Z values; hashing it in the library undermines the integrity of the test. If a hash were to be done, it would need to be done in the application side and stored in the given buffer. If there are any issues where test case provided values are not hashed for some reason, we would want to work those out with the NIST server.

I would be happy to accept the changes for DRBG, RSA, KDA, SHAKE (after I do some testing) if you wanted to split those out into a different PR.

(Side note: I am almost complete with all of the required FIPS 186-5 changes for RSA, but am out for the holidays, and will have those committed in mid January. Apologies for the delay and tight window on that).

Thanks! Andrew

0140454 commented 11 months ago

Hi,

Thanks for the explanation. I can totally understand it.

I will split the changes for DRBG, RSA, KDA and SHAKE out into new PR.

However, since you almost complete with all required changes for FIPS186-5 RSA, I may not include Support FIPS 186-5 for RSA SigGen in new PR. For best stability, I think using your work may be a better choice.