This is an archive
(replace .gov by .rip)

Cryptographic Algorithm Validation Program CAVP

2011 Announcements

[09-8-11] -- New release of the CAVS algorithm validation testing tool to the CST Laboratories (CAVS11.5). This version of the CAVS tool addresses:

  1. 186-3 RSA - Corrected bug in file formatting of RSA Key Generation using Random Primes that are Probably Prime (B.3.3) that was causing the verification of the file to fail.
  2. In 186-3 RSA Signature Verification, added the ability for the IUT to indicate they only support fixed pubic key e values. If they indicate they only support fixed public key values, they must enter at least one value for the public key. They may enter up to 2 values to be tested by the Signature Verification test. All tests will use these public key(s). If this option is not selected, the option "random public key values supported by IUT" must be selected. Then random public keys will be used for the Signature Verification test.
  3. Added an internal prime check to CAVS' 186-3 RSA provable prime generation routine. This does not affect validation of 186-3 RSA.
  4. Changed "Special Processing Request" field in Vendor Info to "Do not post on CAVP website" field. This was the intended purpose of the original "Special Processing Request" field.
  5. Added "Other Special Requests and Notes for CAVP" field to Vendor Info. This field is to be used for all other requests for special processing or notes about the implementation.

The transition period ends December 8, 2011.

As has been the policy in the past:

  1. EFFECTIVE IMMEDIATELY on any new validation requests for implementations of TDES, AES, FIPS 186-2DSA, SHA, RNG, FIPS 186-2 RSA, HMAC, CCM, FIPS 186-2ECDSA, CMAC, DRBG 800-90, Key Agreement Scheme (KAS) FFC, KAS ECC, GCM 800-38D, FIPS186-3 DSA, FIPS186-3ECDSA, FIPS186-3RSA, XTS, and/or the testing of the ECC DLC Primitive Component, the CST lab must use the CAVS 11.5 to validate the IUT.
  2. If a 186-3 RSA validation request for 186-3 RSA Key Generation using Random Primes that are Probably Prime (B.3.3) is in the processing of being validated (files have been generated using a tool prior to CAVS 11.5), please regenerate the files ONLY for this one test - for 186-3 KEYGEN using Random Primes that are Probably Prime (B.3.3). (NOTE this applies to files that have been sent to the vendor and files that have not been sent to the vendor.)
  3. For any algorithm validation (excluding 186-3 RSA Key Generation using Random Primes that are Probably Prime) where a lab has used a version of CAVS prior to CAVS 11.5 to create files and has already sent the sample and request files to the vendor, NIST will accept validations using this tool up through December 8, 2011.
  4. If there are any validation requests where a lab has used a version of CAVS prior to CAVS 11.5 to create files and has not yet sent the appropriate files to the vendor, the only files you would need to regenerate using CAVS 11.5 are those associated with 186-3 RSA Key Generation using Random Primes that are Probably Prime (B.3.3). All other algorithms and tests are the same between CAVS 11.4 and CAVS 11.5.

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


[08-10-11] -- Updated CAVP Frequently Asked Questions (FAQ) document.


[07-14-11] -- New release of the CAVS algorithm validation testing tool to the CST Laboratories (CAVS11.4). This version of the CAVS tool addresses a minor bug fix allowing validation testing for "All of 800-56A except KDF" test to be run.

The transition period ends October 14, 2011.

As has been the policy in the past:

  1. EFFECTIVE IMMEDIATELY on any new validation requests for implementations of TDES, AES, FIPS 186-2DSA, SHA, RNG, FIPS 186-2 RSA, HMAC, CCM, FIPS 186-2ECDSA, CMAC, DRBG 800-90, Key Agreement Scheme (KAS) FFC, KAS ECC, GCM 800-38D, FIPS186-3 DSA, FIPS186-3ECDSA, FIPS186-3RSA, XTS, and/or the testing of the ECC DLC Primitive Component, the CST lab must use the CAVS 11.4 to validate the IUT.
  2. For any algorithm validation request where a lab has used a version of CAVS prior to CAVS 11.4 to create files and has already sent the sample and request files to the vendor, NIST will accept validations using this tool up through October 14, 2011.
  3. If there are any validation requests where a lab has used a version of CAVS prior to CAVS 11.4 to create files and has not yet sent the appropriate files to the vendor, please regenerate everything using CAVS 11.4.

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


[07-08-11] -- New release of the CAVS algorithm validation testing tool to the CST Laboratories (CAVS11.3). This version of the CAVS tool addresses:

  1. KAS - Corrected the order of the Uid and Vid in the Other Information field in the Validity Test files. The order of these id fields was not in the correct order ONLY when an IUT was being tested as the responder.
  2. KAS - Added error checking for the Static scheme (for both FFC and ECC) - the Other Information field must contain the Party U's nonce.
  3. DRBG - The options for prediction resistance support have changed. Implementations that do not support prediction resistance should check the box labeled "Prediction Resistance Not Enabled." Implementations that always use prediction resistance should check the box labeled "Prediction Resistance Enabled" and leave the other box unchecked. Implementations that allow prediction resistance to be either on or off should check both boxes.
  4. CMAC - Past versions of CAVS would occasionally generate values for the CMAC "Verify" tests for small (one byte) MACs that would pass when the fax file indicated they should fail. This has been fixed.
  5. 186-3 ECDSA DSA and RSA - Allow any approved random number generator (DRBG or RNG) to be prerequisites for all of the 186-3 algorithms.
  6. 186-3 RSA - B.3.6 Key Generation method uses prime factors Xp1, Xp2, Xq1, Xq2 that satisfy the length requirements listed in Table B.1. When generating a random number of the desired length, a zero sometimes occurred in the left most position making the length shorter than expected. This has been corrected by forcing a 1 in the left most position.
  7. Other minor bug fixes.

The transition period ends October 8, 2011.

As has been the policy in the past:

  1. EFFECTIVE IMMEDIATELY on any new validation requests for implementations of TDES, AES, FIPS 186-2DSA, SHA, RNG, FIPS 186-2 RSA, HMAC, CCM, FIPS 186-2ECDSA, CMAC, DRBG 800-90, Key Agreement Scheme (KAS) FFC, KAS ECC, GCM 800-38D, FIPS186-3 DSA, FIPS186-3ECDSA, FIPS186-3RSA, XTS, and/or the testing of the ECC DLC Primitive Component, the CST lab must use the CAVS 11.3 to validate the IUT.
  2. For any algorithm validation request (except those algorithms listed in 3 below) where a lab has used a version of CAVS prior to CAVS 11.3 to create files and has already sent the sample and request files to the vendor, NIST will accept validations using this tool up through October 8, 2011.
  3. For algorithm validation requests for KAS where the responder role is being tested, 186-3 RSA where Key Generation method Appendix B.3.6 Generation of Probable Primes with Conditions Based on Auxiliary Probable Primes is being tested, or CMAC implementations allowing 1 byte MACs: : If a lab has generated values for this using a version of CAVS prior to CAVS11.3, the CST must regenerate the files using CAVS11.3.
  4. If there are any validation requests where a lab has used a version of CAVS prior to CAVS 11.3 to create files and has not yet sent the appropriate files to the vendor, please regenerate everything using CAVS 11.3.

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


[05-18-11] -- New release of the CAVS algorithm validation testing tool to the CST Laboratories (CAVS11.2). This version of the CAVS tool addresses:

  1. Several bug corrections.

The transition period ends August 18, 2011.

As has been the policy in the past:

  1. EFFECTIVE IMMEDIATELY on any new validation requests for implementations of TDES, AES, FIPS 186-2DSA, SHA, RNG, FIPS 186-2 RSA, HMAC, CCM, FIPS 186-2ECDSA, CMAC, DRBG 800-90, Key Agreement Scheme (KAS) FFC, KAS ECC, GCM 800-38D, FIPS186-3 DSA, FIPS186-3ECDSA, FIPS186-3RSA, XTS, and/or the testing of the ECC DLC Primitive Component, the CST lab must use the CAVS 11.2 to validate the IUT.
  2. For any algorithm validation request where a lab has used a version of CAVS prior to CAVS 11.2 to create files and has already sent the sample and request files to the vendor, NIST will accept validations using this tool up through August 18, 2011.
  3. For algorithm validation requests for SP800-56A using FFC Static scheme or ECC StaticUnified scheme: If a lab has generated values for this using a version of CAVS prior to CAVS11.2, the CST must regenerate the files using CAVS11.2.
  4. If there are any validation requests where a lab has used a version of CAVS prior to CAVS 11.2 to create files and has not yet sent the appropriate files to the vendor, please regenerate everything using CAVS 11.2.

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


[04-12-11] -- New release of the CAVS algorithm validation testing tool to the CST Laboratories (CAVS11.1). This version of the CAVS tool addresses:

  1. Added DLC primitive only testing to the KAS ECC screen. This tests the functions of the Elliptic Curve Cryptography Cofactor Diffie-Hellman (ECC CDH) Primitive as a component. This means only the function ECC CDH is tested.
  2. Changed the labeling of the existing testing that WAS called “DLC Primitive only” to “All of SP800-56A EXCEPT KDF” which better describes the actually testing.
  3. Correctly labeled what WAS called “Assurances” to “Supporting functions included in the IUT that aren’t described in SP800-56A”, (e.g., DSA Key Generation, etc.)
  4. Increased the number of iterations for each round of FIPS186-3 RSA Key Generation.
  5. Corrected a bug in KASFFC that affected the prerequisites expected. When “Full Public Key Validation” is selected, CAVS erroneously required DSA as a prerequisite. This is not true and has been corrected.

The transition period ends July 12, 2011.

As has been the policy in the past:

  1. EFFECTIVE IMMEDIATELY on any new validation requests for implementations of TDES, AES, FIPS 186-2DSA, SHA, RNG, FIPS 186-2 RSA, HMAC, CCM, FIPS 186-2ECDSA, CMAC, DRBG 800-90, Key Agreement Scheme (KAS) FFC, KAS ECC, GCM 800-38D, FIPS186-3 DSA, FIPS186-3ECDSA, FIPS186-3RSA, XTS, and/or the testing of the ECC DLC Primitive Component, the CST lab must use the CAVS 11.1 to validate the IUT.
  2. For any algorithm validation request where a lab has used a version of CAVS prior to CAVS 11.1 to create files and has already sent the sample and request files to the vendor, NIST will accept validations using this tool up through July 12, 2011.
  3. If there are any validation requests where a lab has used a version of CAVS prior to CAVS 11.1 to create files and has not yet sent the appropriate files to the vendor, please regenerate everything using CAVS 11.1.

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


[03-03-11] -- New release of the CAVS algorithm validation testing tool to the CST Laboratories (CAVS11.0). This version of the CAVS tool addresses:

  1. Addition of Validation testing for 186-3 RSA
  2. Removal of the Assurances from the 186-3DSA and ECDSA validations. The selection of testing functions denotes whether or not an assurance could be met. The assurances are out of scope of the algorithm implementation.
  3. Removal of the Assurances from the KAS validations. The selection of testing functions denotes whether or not an assurance could be met. The assurances are out of scope of the algorithm implementation.
  4. Removal of the Assurance that "An XTS-AES key shall not be associated with more than one key scope." from XTS. This is out of scope of the algorithm implementation.
  5. Correction of bug in GCM which denoted a correct answer as wrong. Caused by truncation of answer and the first couple bytes matching the correct answer.
  6. Addition of information to the log file for GCM Decrypt to indicate why a value fails
  7. Modification of wording for prerequisite of AES for GCM. Prerequisite for AES said only ECB. Changed wording to include any mode with forward cipher function. This includes ECB and CBC encrypt, CFB and OFB encr and decr and CTR (which requires ECB so is really ECB).
  8. Removal of prerequisite of DRBG from ECDSA2 SigVer. Removed from Verify function because it would not verify because didn't have DRBG specified. Also removed from cover letter.
  9. The ECDSA Prerequisite screen is shared between ECDSA and ECDSA2. ECDSA can use RNG but ECDSA2 can not. The bug that prevented ECDSA from specifying an RNG prerequisite has been corrected.
  10. Other minor modifications.

The transition period ends June 3, 2011.

As has been the policy in the past:

  1. EFFECTIVE IMMEDIATELY on any new validation requests for implementations of TDES, AES, FIPS 186-2DSA, SHA, RNG, FIPS 186-2 RSA, HMAC, CCM, FIPS 186-2ECDSA, CMAC, DRBG 800-90, Key Agreement Scheme (KAS) FFC, KAS ECC, GCM 800-38D, FIPS186-3 DSA, FIPS186-3ECDSA, FIPS186-3RSA, and/or XTS, the CST lab must use the CAVS 11.0 to validate the IUT.
  2. For any algorithm validation request where a lab has used a version of CAVS prior to CAVS 11.0 to create files and has already sent the sample and request files to the vendor, NIST will accept validations using this tool up through June 3, 2011.
  3. If there are any validation requests where a lab has used a version of CAVS prior to CAVS 11.0 to create files and has not yet sent the appropriate files to the vendor, please regenerate everything using CAVS 11.0.

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

 

 

Created October 05, 2016, Updated November 24, 2020