U.S. flag   An unofficial archive of your favorite United States government website
Dot gov

Official websites do not use .rip
We are an unofficial archive, replace .rip by .gov in the URL to access the official website. Access our document index here.

Https

We are building a provable archive!
A lock (Dot gov) or https:// don't prove our archive is authentic, only that you securely accessed it. Note that we are working to fix that :)

Cryptographic Algorithm Validation Program CAVP

2017 Announcements

  1. CAVS would become unresponsive if Modify New Submission was selected several times. This has been corrected.
  2. On the Modify New Submission screen, some words were not displayed fully. This has been corrected.
  3. The algorithm validation numbers are now checked to assure they are numeric. If they are not, an error message is displayed.
  4. When preparing change request, if any information was updated EXCEPT the implementation type information, the implementation type information was cleared. This has been corrected.
  5. Added this instruction to the Submission Guidance Jan 2017 for New Cryptographic Algorithm Implementation, Submission Guidance Jan 2017 for Cryptographic Algorithm Implementation Change Request, and Submission Guidance Jan 2017 for Cryptographic Algorithm Implementation Update Request: The email must be in plaintext format.

 

The transition period ends April 30, 2017. This means CAVS21.0 can be used up until April 30, 2017. After that, CAVS21.2 must be used.

As has been the policy in the past:

  1. EFFECTIVE IMMEDIATELY on any new validation requests for implementations of TDES, AES, SHA, HMAC, CCM, CMAC, DRBG 800-90A, Key Agreement Scheme (KAS) FFC, KAS ECC, GCM 800-38D (including GMAC and XPN), FIPS186-4 DSA, FIPS186-4 ECDSA, FIPS186-4 RSA, XTS, the ECC DLC Primitive Component, SP800-108 KDF, the KDFs in SP800-135, RSA Signature Generation Component testing for PKCS1.5 and/or PKCS PSS, the ECDSA2 Signature Generation Component, the RSADP component, the SP 800-38F Key Wrapping and/or SHA-3 or SHAKE, the CST lab must use the CAVS21.1 to validate the IUT.
  2. For any algorithm validation request where a lab has used a version of CAVS prior to CAVS 21.2 to create files and has already sent the sample and request files to the vendor, CAVS 21.2 shall be used to validate the response files. The files generated with CAVS 21.1 are compatible with CAVS 21.2. NIST will accept files generated with CAVS 21.1 up through April 30, 2017. They should all be validated with CAVS 21.2.
  3. For any algorithm validation request where a lab has used a version of CAVS prior to CAVS 21.2 to create files and has already sent the sample and request files to the vendor, CAVS 21.2 shall be used to validate the response files. The files generated with CAVS 21.1 are compatible with CAVS 21.2. NIST will accept files generated with CAVS 21.1 up through April 30, 2017. They should all be validated with CAVS 21.2
  4. Effective immediately, CAVS 21.2 shall be used to submit change and update requests UNLESS the lab making the change/updated does not have the original submission files.

The CAVP will also review special conditions on a case-by-case basis.


  1. Implementation type for software would not save. Corrected.
  2. Increased length of Implementation name again.

The transition period ends April 12, 2017. This means CAVS21.0 can be used up until April 12, 2017. After that, CAVS21.1 must be used.

As has been the policy in the past:

  1. EFFECTIVE IMMEDIATELY on any new validation requests for implementations of TDES, AES, SHA, HMAC, CCM, CMAC, DRBG 800-90A, Key Agreement Scheme (KAS) FFC, KAS ECC, GCM 800-38D (including GMAC and XPN), FIPS186-4 DSA, FIPS186-4 ECDSA, FIPS186-4 RSA, XTS, the ECC DLC Primitive Component, SP800-108 KDF, the KDFs in SP800-135, RSA Signature Generation Component testing for PKCS1.5 and/or PKCS PSS, the ECDSA2 Signature Generation Component, the RSADP component, the SP 800-38F Key Wrapping and/or SHA-3 or SHAKE, the CST lab must use the CAVS21.1 to validate the IUT.
  2. For any algorithm validation request where a lab has used a version of CAVS prior to CAVS 21.1 to create files and has already sent the sample and request files to the vendor, NIST will accept validations of acceptable algorithms using this tool up through April 12, 2017.
  3. If there are any validation requests where a lab has used a version of CAVS that has not expired to create files and has not yet sent the appropriate files to the vendor, please regenerate everything using CAVS 21.1.
  4. Effective immediately, CAVS 21.1 shall be used to submit change and update requests UNLESS the lab making the change/updated does not have the original submission files.
  5. New documentation on CAVP Algorithm Submission Guidance is included. It is required that this new and updated guidance be followed on algorithm submissions.

 

The CAVP will also review special conditions on a case-by-case basis.

  1. Added Change Request Submission ability to CAVS tool. Can use this to change information for vendor and implementation information only.
  2. Added Update Request Submission ability to CAVS tool. Use when have changes to vendor and implementation information AND have new or additional testing of algorithms.
  3. X931 SigGen mod 4096 SHA224 was not being saved in inf file. This has been corrected.
  4. Increased length of Implementation Name, Firmware version number and Operating Environment
  5. HMAC Added error checking to assure SHA2 or SHA3 is selected for HMAC-SHA224, HMAC-SHA256, HMAC-SHA384, HMAC-SHA512.
  6. If nothing is tested with GCM, the inf file was saying GCMtested=true even though the test was not run. This was corrected to say GCMtested=false.
  7. Corrected entry in inf file for GCM prerequisite if select In same implementation it was putting n/a in inf file.
  8. Added ability to specify unique CAVP ID as a prerequisite to indicate when the validation number hasn't been assigned and when the prerequisite submission is not in the same implementation.
  9. Added instructions pertaining to TPM v2.0 testing. TPMv2 Specification, Part1, Section 11.4.9 states that the TPMv2.0 KDF is a NIST SP 800-108 compliant HMAC-KDF. Therefore, SP800-108 validation testing is required to validate TPM v2.0. As in the past, TPMv1.2 is tested using the SP800-135 testing.

 

The transition period ends April 5, 2017. This means CAVS20.2 can be use up until April 5, 2017. After that, CAVS21.0 must be used.As has been the policy in the past:

 

  1. EFFECTIVE IMMEDIATELY on any new validation requests for implementations of TDES, AES, SHA, HMAC, CCM, CMAC, DRBG 800-90A, Key Agreement Scheme (KAS) FFC, KAS ECC, GCM 800-38D (including GMAC and XPN), FIPS186-4 DSA, FIPS186-4 ECDSA, FIPS186-4 RSA, XTS, the ECC DLC Primitive Component, SP800-108 KDF, the KDFs in SP800-135, RSA Signature Generation Component testing for PKCS1.5 and/or PKCS PSS, the ECDSA2 Signature Generation Component, the RSADP component, the SP 800-38F Key Wrapping and/or SHA-3 or SHAKE, the CST lab must use the CAVS21.0 to validate the IUT.
  2. For any algorithm validation request where a lab has used a version of CAVS prior to CAVS 21.0 to create files and has already sent the sample and request files to the vendor, NIST will accept validations of acceptable algorithms using this tool up through April 5, 2017.
  3. If there are any validation requests where a lab has used a version of CAVS that has not expired to create files and has not yet sent the appropriate files to the vendor, please regenerate everything using CAVS 21.0.
  4. Effective immediately, CAVS 21.0 shall be used to submit change and update requests UNLESS the lab making the change/updated does not have the original submission files.
  5. New documentation on CAVP Algorithm Submission Guidance is included. It is required that this new and updated guidance be followed on algorithm submissions.
  6.  

The CAVP will also review special conditions on a case-by-case basis.


 

 

Created October 05, 2016, Updated February 24, 2022