NIST Logo and ITL Banner Link to the NIST Homepage Link to the ITL Homepage Link to the NIST Homepage
Search CSRC:

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. 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. 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.

[06-07-10] -- New release of the CAVS algorithm validation testing tool to the CST Laboratories(CAVS10.1). This version of the CAVS tool addresses a correction to the Key Agreement Schemes ECC with No Key Confirmation (KAS ECC No KC) screen. (When parameter set EA was selected, the radio button for the curve size would only allow P-192 to be selected.) This has been corrected.

The transition period ends September 7, 2010.

As has been the policy in the past:

  1. EFFECTIVE IMMEDIATELY on any new validation requests for implementations of TDES, AES, 186-2 DSA, SHA, RNG, RSA, HMAC, CCM, 186-2 ECDSA, CMAC, DRBG 800-90, Key Agreement Scheme (KAS) FFC, KAS ECC, GCM 800-38D, 186-3 DSA, 186-3 ECDSA and/or XTS, the CST lab must use the CAVS 10.1 to validate the IUT.
  2. For any algorithm validation request where a lab has used a version of CAVS prior to CAVS 10.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 September 7, 2010.
  3. If there are any validation requests where a lab has used a version of CAVS prior to CAVS 10.1 to create files and has not yet sent the appropriate files to the vendor, please regenerate everything using CAVS 10.1.
The CAVP will also review special conditions on a case-by-case basis.

[05-27-10] -- New release of the CAVS algorithm validation testing tool to the CST Laboratories (CAVS10.0). This version of the CAVS tool addresses

  1. Validation testing for FIPS 186-3 ECDSA
  2. Addition of prerequisites for KAS
  3. Addition of error checking on the values entered for KAS, CCM, and CMAC to assure they are valid values
  4. Fixed a bug in KAS ECC when EE parameter set was used
  5. Removed some extraneous information in the cover letter
  6. XTS restriction on Data Unit Length – enforcing the minimum to be block size
  7. Modified format of Summary files to aid us in the automation of NIST’s internal database. This should be transparent to the testing laboratories and the processing of the CAVS tool. Included adding additional fields to coincide with the importing of information on the validation lists.

The transition period ends August 27, 2010.

As has been the policy in the past:

  1. EFFECTIVE IMMEDIATELY on any new validation requests for implementations of TDES, AES, 186-2 DSA, SHA, RNG, RSA, HMAC, CCM, 186-2 ECDSA, CMAC, DRBG 800-90, Key Agreement Scheme (KAS) FFC, KAS ECC, GCM 800-38D, 186-3 DSA, 186-3 ECDSA and/or XTS, the CST lab must use the CAVS 10.0 to validate the IUT.
  2. For any algorithm validation request where a lab has used a version of CAVS prior to CAVS 10.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 August 27, 2010.
  3. If there are any validation requests where a lab has used a version of CAVS prior to CAVS 10.0 to create files and has not yet sent the appropriate files to the vendor, please regenerate everything using CAVS 10.0.
The CAVP will also review special conditions on a case-by-case basis.

[03-31-10] -- New release of the CAVS algorithm validation testing tool to the CST Laboratories (CAVS9.0). This version of the CAVS tool addresses

  1. Addition of validation test for NIST SP800-38E: XTS-AES Mode for Confidentiality on Storage Devices
  2. Addtion of tests for FIPS 186-3 Section A.1.2, "Construction and Validation of the Provable Primes p and q," FIPS 186-3 Section A.2.3, "Verifiable Canonical Generation of the Generator G,", and FIPS 186-3 Section A.2.4, "Validation Routine when the Canonical Generation of the Generator G was Used."
  3. Modification of GCM Tab to allow zero-length AAD (min and max length of AAD can now be equal to zero)
  4. Modification of GCM Tab to allow selection of both methods for IV generation 8.2.1 and 8.2.2 instead of only one.
  5. In response to Implementation Guidance D.2 Acceptable Key Establishment Protocols, which states that an implementation of SP800-56A can use additional key derivation functions (KDFs) specified in D.2 that are not included in SP800-56A, addition of validation tests that test the processing of all functions up to and including the calculation of the shared secret value (Z) in SP800-56A. This testing is required for implementations adhering to D.2 to assure that the other processing that adheres to the specifications in SP800-56A is correct. These implementations will not receive a KAS Validation. But they will be acknowledged for going through the testing.
  6. Additional information is being requested on the screens for SP800-56A to satisfy the CAVS-addressable requirements in the special publication.
  7. Addition of the entry of prerequisites for most algorithms. This enforces that the laboratory has supplied the source of the prerequisite algorithms.
  8. Correction of a minor bug and pointer problem in ECDSA
  9. Modified format of summary files to aid the CAVP in the automation of the CAVP's internal database.

The transition period ends June 30, 2010.

As has been the policy in the past:

  1. EFFECTIVE IMMEDIATELY on any new validation requests for implementations of TDES, AES, DSA, SHA, RNG, RSA, HMAC, CCM, ECDSA, CMAC, DRBG 800-90, Key Agreement Scheme (KAS) FFC, KAS ECC, GCM 800-38D, FIPS186-3 DSA2 and/or XTS, the CST lab must use the CAVS 9.0 to validate the IUT.
  2. For any algorithm validation request where a lab has used a version of CAVS prior to CAVS 9.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 30, 2010.
  3. If there are any validation requests where a lab has used a version of CAVS prior to CAVS 9.0 to create files and has not yet sent the appropriate files to the vendor, please regenerate everything using CAVS 9.0.
The CAVP will also review special conditions on a case-by-case basis.

[09-17-09] -- New release of the CAVS algorithm validation testing tool to the CST Laboratories (CAVS8.1). This version of the CAVS tool addresses several minor modifications and enhancements to CAVS including the Addition of a cover letter template, the addition of more efficient elliptic curve routines for NIST binary (e.g.., B-163 and K-571) curves, and the modification of several minor issues.

The transition period ends December 17, 2009.

As has been the policy in the past:

  1. EFFECTIVE IMMEDIATELY on any new validation requests for implementations of TDES, AES, DSA, SHA, RNG, RSA, HMAC, CCM, ECDSA, CMAC, DRBG 800-90, Key Agreement Scheme (KAS) FFC, KAS ECC, GCM 800-38D and/or FIPS186-3 DSA2(see exception below in 2), the CST lab must use the CAVS 8.1 to validate the IUT.
  2. For any algorithm validation request where a lab has used a version of CAVS prior to CAVS 8.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 December 17, 2009.
  3. If there are any validation requests where a lab has used a version of CAVS prior to CAVS 8.1 to create files and has not yet sent the appropriate files to the vendor, please regenerate everything using CAVS 8.1.
The CAVP will also review special conditions on a case-by-case basis.

[08-17-09] -- Posting of the CAVS Management Manual. The purpose of the CAVP Management Manual is to provide effective guidance for the management of the CAVP and other parties in the validation process. The CAVP Management Manual applies to the CAVP Validation Authorities, the CST laboratories, and the vendors who participate in the program. Consumers who purchase validated cryptographic modules and validated cryptographic algorithm implementations may also be interested in the contents of this manual. This manual outlines the management activities and specific responsibilities of the various participating groups. This manual does not include any cryptographic standards.

[07-02-09] -- New release of the CAVS algorithm validation testing tool to the CST Laboratories (CAVS8.0). This version of the CAVS tool activates the FIPS 186-3 DSA2 validation testing with the exception of generation and validation of provably prime domain parameters p and q and canonical generation and validation of domain parameter g. It also requires the IUT to specify the assurances necessary for valid digital signatures specified in FIPS 186-3.

The transition period ends October 02, 2009.

As has been the policy in the past:

  1. EFFECTIVE IMMEDIATELY on any new validation requests for implementations of TDES, AES, DSA, SHA, RNG, RSA, HMAC, CCM, ECDSA, CMAC, DRBG 800-90, Key Agreement Scheme (KAS) FFC, KAS ECC, GCM 800-38D and/or FIPS186-3 DSA2(see exception below in 2), the CST lab must use the CAVS 8.0 to validate the IUT
  2. Implementations of FIPS186-3 DSA2 supporting the generation and validation of provably prime domain parameters p and q and canonical generation and validation of domain parameter g, ECDSA2 and/or RSA2 must be vendor-affirmed according to the specifications in I.G 1.15. All new DSA2 implementations supporting the above listed domain parameter generation and validation methods, ECDSA2 and RSA2 algorithm validation requests received after the release of CAVS8.0 shall be vendor affirmed.
  3. For any algorithm validation request where a lab has used a version of CAVS prior to CAVS8.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 October 2, 2009.
  4. If there are any validation requests where a lab has used a version of CAVS prior to CAVS8.0 to create files and has not yet sent the appropriate files to the vendor, please regenerate everything using CAVS8.0.
The CAVP will also review special conditions on a case-by-case basis.
[04-15-09] -- New release of the CAVS algorithm validation testing tool to the CST Laboratories (CAVS7.4). This version of the CAVS tool adds the capability to test DRBG (NIST SP 800-90) implementations that do not have the optional reseed function. Each DRBG mechanism tab has a check box to indicate that the reseed function was not implemented. If checked, the generated request files provide inputs for the instantiate and generate functions only. The CAVS-generated TestedInfo.txt file indicates that the implementation does not support the reseed function.
The transition period ends July 06, 2009.
As has been the policy in the past:
  1. EFFECTIVE IMMEDIATELY on any new validation requests for implementations of TDES, AES, DSA, SHA, RNG, RSA, HMAC, CCM, ECDSA, CMAC, DRBG 800-90, Key Agreement Scheme (KAS) FFC, KAS ECC and/or GCM 800-38D, the CMT lab must use the CAVS 7.4 to validate the IUT.
  2. For any algorithm validation request where a lab has used a version of CAVS prior to CAVS7.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 July 6, 2009. (Note that the transition date for CAVS 7.4 will be the same as CAVS 7.2 and CAVS 7.3.)
  3. Because CAVS 7.4 makes a very minor addition that does not affect any existing operations of the tool, for any algorithm validation request where a lab used CAVS 7.2 or CAVS 7.3 to create files, CAVS 7.4 can be used to validate these files.
  4. If there are any validation requests where a lab has used a version of CAVS prior to CAVS7.2 to create files and has not yet sent the appropriate files to the vendor, please regenerate everything using CAVS 7.4.

The CAVP will also review special conditions on a case-by-case basis.
[04-08-09] -- New release of the CAVS algorithm validation testing tool to the CST Laboratories (CAVS7.3). This version of the CAVS tool fixes a bug in the Utilities->Display Status function. The bug caused CAVS to end abnormally.
The transition period ends July 06, 2009.
As has been the policy in the past:
  1. EFFECTIVE IMMEDIATELY on any new validation requests for implementations of TDES, AES, DSA, SHA, RNG, RSA, HMAC, CCM, ECDSA, CMAC, DRBG 800-90, Key Agreement Scheme (KAS) FFC, KAS ECC and/or GCM 800-38D, the CMT lab must use the CAVS 7.3 to validate the IUT.

  2. For any algorithm validation request where a lab has used a version of CAVS prior to CAVS7.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 July 6, 2009. (Note that the transition date will be the same as CAVS7.2.)

  3. Because CAVS7.3 fixes a very minor bug that only affects the ability to display the status of the tests and not the other operations of the tool, for any algorithm validation request where a lab used CAVS7.2 to create files, CAVS7.3 can be used to validate these files.

  4. If there are any validation requests where a lab has used a version of CAVS prior to CAVS7.2 to create files and has not yet sent the appropriate files to the vendor, please regenerate everything using CAVS 7.3.

The CAVP will also review special conditions on a case-by-case basis.
[04-06-09] -- New release of the CAVS algorithm validation testing tool to the CMT Laboratories (CAVS7.2).Version 7.2 of the CAVS tool includes several minor corrections and additions. They include:
  • Minor correction to KAS ECC screen - corrected the wording on the screen - min of h should be max of h
  • Minor correction to KAS ECC testing - corrected the length of a field which was causing KAS EEC testing to exit abnormally
  • In the TestedInfo.txt file, added prerequisite of RNG to GCM if option 2 is selected
  • In the TestedInfo.txt file, added statement for CMAC to ask for the prerequisite of TDES and/or AES, if applicable.
  • Modified the SHA screen to allow the indication of "null string not supported".
  • Modified the SHA screen to only have to enter "Byte only" once to apply to all supported SHA sizes.
The transition period ends July 06, 2009.
As has been the policy in the past:
  1. EFFECTIVE IMMEDIATELY on any new validation requests for implementations of TDES, AES, DSA, SHA, RNG, RSA, HMAC, CCM, ECDSA, CMAC, DRBG 800-90, Key Agreement Scheme (KAS) FFC, KAS ECC and/or GCM 800-38D, the CMT lab must use the CAVS 7.2 to validate the IUT.

  2. For any algorithm validation request where a lab has used a previous version of CAVS 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 06, 2009. The tool used to generate the files must be used to validate the files. For example, if CAVS7.1 was used to generate test vectors, then CAVS7.1 must be used to verify these values.

  3. If there are any validation requests where a lab has used a previous version of CAVS to create files and has not yet sent the appropriate files to the vendor, please regenerate everything using CAVS7.2.

The CAVP will also review special conditions on a case-by-case basis.
[03-12-09] -- New release of the CAVS algorithm validation testing tool to the CMT Laboratories (CAVS7.1). In addition to minor modifications to enhance the tool, Version 7.1 of the CAVS tool adds testing for the draft of FIPS 186-3, Digital Signature Standard, Digital Signature Algorithm and file formating changes to the NIST SP 800-90 (DRBG) files to make them more similar to those used for other algorithms. As of the CAVS 7.1 release date, FIPS 186-3 is still in draft. No validations will be processed for this algorithm.
The transition period ends June 12, 2009.
As has been the policy in the past:
  1. EFFECTIVE IMMEDIATELY on any new validation requests for implementations of TDES, AES, DSA, SHA, RNG, RSA, HMAC, CCM, ECDSA, CMAC, DRBG 800-90, Key Agreement Scheme (KAS) FFC, KAS ECC and/or GCM 800-38D, the CMT lab must use the CAVS 7.1 to validate the IUT.

  2. For any algorithm validation request where a lab has used a previous version of CAVS 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 12, 2009. The tool used to generate the files must be used to validate the files. For example, if CAVS7.0 was used to generate test vectors, then CAVS7.0 must be used to verify these values.

  3. If there are any validation requests where a lab has used a previous version of CAVS to create files and has not yet sent the appropriate files to the vendor, please regenerate everything using CAVS7.1.

The CAVP will also review special conditions on a case-by-case basis.
[12-24-2008] -- New release of the CAVS algorithm validation testing tool to the CMT Laboratories (CAVS7.0). Version 7.0 of the CAVS tool adds testing for NIST SP 800-56A Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography and NIST SP 800-38D Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC.
In addition, file formating changes have been made to the CCM Decrypt-Verification Process Test.
The transition period ends March 24, 2009.
As has been the policy in the past:
  1. For any algorithm validation request where a lab has used a previous version of CAVS to create files and has already sent the sample and request files to the vendor, NIST will accept validations using this tool up through March 24, 2009. The tool used to generate the files must be used to validate the files. For example, if CAVS6.1 was used to generate test vectors, then CAVS6.1 must be used to verify these values.
  2. If there are any validation requests where a lab has used a previous version of CAVS to create files and has not yet sent the appropriate files to the vendor, please regenerate everything using CAVS7.0.
Prior to the release of CAVS7.0, the CMVP allowed vendor affirmation for SP800-56A implementations(IG1.12) and vendor affirmation for SP800-38D implementations (IG.1.13). During the transition period, the vendor has the option of either providing the vendor affirmation in FIPS140-2 IG1.12 or IG1.13 or going through the validation testing now available in CAVS7.0. The transition period for accepting vendor affirmation for SP800-56A is being determined but will exceed the 3 months specified above. Please see the CMVP Announcements for further information.
The CAVP will also review special conditions on a case-by-case basis.
[02-06-2008] -- New release of the CAVS algorithm validation testing tool to the CMT Laboratories (CAVS6.1). The CAVS 6.1 tool fixes an error with HMAC_DRBG SP 800-90 DRBG testing. CAVS 6.0 was erroneously using the Hash_DRBG mechanism to generate returned bits for the HMAC_DRBG tests in the .fax files. A second modification made to CAVS6.1 regarding SP 800-90 DRBG testing involved changing the requested number of bits to always be a multiple of the blocksize.
With regards to DSA validation testing, CAVS6.1 DSA screens have been modified to only allow modulus sizes providing at least 80 bits of security as required by SP800-57; i.e., only the 1024 bit modulus size is allowable.
The transition period ends May 6, 2008.
As has been the policy in the past:
1. EFFECTIVE IMMEDIATELY on any new validation requests for implementations of TDES, AES, DSA, SHA, RNG, DRBG, RSA, ECDSA, HMAC, CCM and/or CMAC, the CMT lab must use the CAVS 6.1 to validate the IUT.
2. For any algorithm validation request where a lab has used a previous version of CAVS to create files and has already sent the sample and request files to the vendor, NIST will accept validations using this tool up through May 6, 2008.
3. The exception to (2.) above is SP 800-90 DRBG testing for the HMAC_DRBG mechanism using any SHA size. CAVS 6.1 must be used for all HMAC_DRBG validation submissions.
4. If there are any validation requests where a lab has used a previous version of CAVS to create files and has not yet sent the appropriate files to the vendor, please regenerate everything using CAVS 6.1.
[11-15-2007] -- New release of the CAVS algorithm validation testing tool to the CMT Laboratories (CAVS6.0). Verison 6.0 of the CAVS tool adds testing for NIST SP 800-90 Deterministic Random Bit Generators.
The transition period ends February 15, 2008.
As has been the policy in the past:
  1. For any algorithm validation request where a lab has used a previous version of CAVS to create files and has already sent the sample and request files to the vendor, NIST will accept validations using this tool up through February 15, 2008. The tool used to generate the files must be used to validate the files. For example, if CAVS5.3 was used to generate test vectors, then CAVS5.3 must be used to verify these values.
  2. If there are any validation requests where a lab has used a previous version of CAVS to create files and has not yet sent the appropriate files to the vendor, please regenerate everything using CAVS6.0.
Prior to the release of CAVS6.0, the CMVP allowed vendor affirmation for SP800-90 DRBG implementations. During the transition period, the vendor has the option of either providing the vendor affirmation in FIPS140-2 IG1.12 or going through the validation testing now available in CAVS6.0. Please see the CMVP Announcements for further information.
The CAVP will also review special conditions on a case-by-case basis.
[10-16-2006] [09-28-2006] New release of the CAVS algorithm validation testing tool to the CMT Laboratories (CAVS5.2). Version 5.2 of the CAVS tool includes the addition of tests to verify the absence of an identified RSA X9.31 and PKCS#1 V1.5 algorithmic implementation vulnerability. Information on this vulnerability can be found at the Computer Security Resource Center (CSRC) October 12, 2006 News. A statement discussing the attack is available. CAVS5.2 also includes several modifications to the existing algorithm validation tests to provide requested enhancements to the tool. Additional information can be found at: Digital Signature Standard (DSS)
The transition period ends December 31, 2006.
As has been the policy in the past:
  1. For any algorithm validation request where a lab has used a previous version of CAVS 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 31, 2006.
  2. If there are any validation requests where a lab has used a previous version of CAVS to create files and has not yet sent the appropriate files to the vendor, please regenerate everything using CAVS5.2.
  3. It is strongly advised that any CMVP cryptographic module in the pre-validation phase re-test the RSA implementations with the new version of CAVS.
  4. After December 31, 2006, all new received test reports to the CMVP pre-validation queue must use the CAVS5.2 to validate RSA.

The CAVP will also review special conditions on a case-by-case basis.
For all validated cryptographic modules that incorporate RSA, the CMVP and CAVP strongly suggest re-testing of the RSA algorithmic implementations to determine if the vulnerability is present.
  • If new CAVP testing is performed, and the vulnerability is determined not to be present, the CMTL can send a letter to the CAVP along with the ZIP'ed CAVS 5.2 files requesting a new algorithm certificate printed to replace the already issued certificate referencing the new version of CAVS. Note that the certificate number will not change. Only the reference to the version of the CAVS tool will be changed.
  • If CAVP testing is performed and the vulnerability is discovered, the following revalidation process shall be followed:
    • The algorithm implementation is changed to remove the vulnerability resulting in a different version number,
    • Submit the new test results to the CAVP for the new version of the implementation. A new algorithm certificate will be issued for the new version of the implementation. The certificate will reference CAVS5.2.
    • A revalidation letter can be submitted to the CMVP confirming that the only change to the module is to the RSA algorithmic implementation to correct the identified vulnerability; provide the reference to the new RSA algorithmic validation certificate; and provide a new version for the module. The CMVP will update the existing FIPS 140-1 or FIPS 140-2 module certificate web site entry to reference the new RSA algorithmic validation certificate and the new module version number associated with that certificate. No new FIPS 140-2 validation certificate will be issued. An updated Security Policy is required to include the new information. Any other changes to the validated cryptographic module shall handled in accordance with IG G.8 - Revalidation Requirements.

Please direct any CAVP or CMVP questions to the appropriate contact.
[04-03-2006] New release of the CAVS algorithm validation testing tool to the CMT Laboratories (CAVS5.0).Version 5.0 of the CAVS tool includes the addition of a validation test suite for the CMAC algorithm. Documentation describing the CMAC validation tests is located in the CMACVS document accessible via our webpage. CAVS5.0 also includes several modifications to the existing algorithm validation tests to provide requested enhancements to the tool.

The transition period ends July 3, 2006.
As has been the policy in the past:
  1. EFFECTIVE IMMEDIATELY on any new validation requests for implementations of TDES, AES, DSA, SHA, RNG, RSA, ECDSA, HMAC, CCM and/or CMAC, the CMT lab must use the CAVS5.0 to validate the IUT.
  2. For any algorithm validation request where a lab has used a previous version of CAVS 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 3, 2006.
  3. If there are any validation requests where a lab has used a previous version of CAVS to create files and has not yet sent the appropriate files to the vendor, please regenerate everything using CAVS5.0.

The CAVP will also review special conditions on a case-by-case basis.
[05-11-2005] New release of the CAVS algorithm validation testing tool to the CMT Laboratories (CAVS4.6). Version 4.6 of the CAVS tool includes a couple of minor modifications. These modifications include:

The transition period ends July 3, 2006.
As has been the policy in the past:
  1. For HMAC: Enforcing the minimum length allowed for the key size. As specified by FIPS PUB 198 The Keyed-Hash Message Authentication Code (HMAC) Section 3 Cryptographic Keys, it states: "The size of the key, K, shall be equal to or greater than L/2, where L is the size of the hash function output." The minimum key size is dependent on the hash function supported by the HMAC implementation and is specified on each screen for HMAC.
  2. For DES and Triple-DES: The message displayed after validating results has been modified to indicate whether or not the tests have passed successfully.

The transition period ends August 11, 2005.
As has been the policy in the past:
  1. EFFECTIVE IMMEDIATELY on any new validation requests for implementations of DES, Triple-DES, AES, DSA, SHS, RNG, RSA, ECDSA, HMAC and/or CCM, the CMT lab must use the CAVS4.6 to validate the IUT.
  2. For any algorithm validation request where a lab has used CAVS4.5 to create files and has already sent the sample and request files to the vendor, NIST will accept validations using this tool during the transition period which expires August 11, 2005. The CMT Laboratory should contact those vendors to inform them that the algorithm validation files supplied to them will expire at the end of the transition period. If the vendor has not returned the response files by that time, the request and sample files will have to be regenerated by the CAVS4.6 tool and the vendor will have to regenerate the response files.
  3. If there are any validation requests where a lab has used a previous version of CAVS to create files and has not sent the appropriate files to the vendor yet, please regenerate everything using CAVS4.6.

The CAVP will also review special conditions on a case-by-case basis.
[01-31-2005] New release of the CAVS algorithm validation testing tool to the CMT Laboratories
  • New RNG algorithm testing
    • Algorithm testing available for NIST-Recommended Random Number Generator Based on ANSI X9.31 Appendix A.2.4 Using the 3-Key Triple DES and AES Algorithms.
    • During the transition period, ANSI X9.31 RNG implementations using 3-Key Triple-DES and AES algorithms will continue to be recognized as FIPS Approved "vendor affirmed" or referenced to the new algorithm certificate if available for FIPS 140-2 validations. After the transition period, these RNG implementations will only be recognized on new FIPS 140-2 validations as FIPS Approved when referenced to an algorithm certificate.
    • All references to RNG on FIPS 140-2 validation certificates that have RNG certificates will be referenced as RNG (Cert. nnn).

The transition period ends April 30, 2005. New FIPS 140-2 validation test reports received from CMT Laboratories after the transition period must conform to the new algorithm testing schemes indicated above. For FIPS 140-2 re-validations received after April 30, 2005, if the security relevant changes do not require new algorithm testing, new algorithm testing is not required. If an algorithm is changed or added, that algorithm must conform to the new algorithm testing schemes indicated above.
For algorithm validation requests where a CMT Laboratory has used CAVS4.3 to create files and has already sent the sample and request files to the vendor, NIST will accept validations using the old tools during the transition period. The CMT Laboratory should contact those vendors to inform them that the algorithm validation files supplied to them will expire at the end of the transition period. If the vendor has not returned the response files by that time, the request and sample files will have to be regenerated by the CAVS4.4 tool and the vendor will have to regenerate the response files. The CMVP will also review special conditions on a case-by-case basis.
[09-01-2004] New release of the CAVS algorithm validation testing tool to the CMT Laboratories (CAVS4.0)
  • New ECDSA algorithm testing
    • Testing is now available for conformance to the ECDSA algorithm.
    • During the transition period, ECDSA algorithms will continue to be recognized as FIPS Approved "vendor affirmed" or referenced to the new algorithm certificate if available for FIPS 140-2 validations. After the transition period, ECDSA will only be recognized on new FIPS 140-2 validations as FIPS Approved when referenced to an algorithm certificate.
    • All references to ECDSA on FIPS 140-2 validation certificates that have ECDSA certificates will be referenced as ECDSA (Cert. nnn).
  • New HMAC algorithm testing
    • Testing is now available for conformance to the HMAC algorithm.
    • During the transition period, the HMAC algorithm will continue to be recognized as FIPS Approved "vendor affirmed" or referenced to the new algorithm certificate if available for FIPS 140-2 validations. After the transition period, HMAC will only be recognized on new FIPS 140-2 validations as FIPS Approved when referenced to an algorithm certificate.
    • All references to HMAC on FIPS 140-2 validation certificates that have HMAC certificates will be referenced as HMAC (Cert. nnn).
  • New CCM algorithm testing
    • Testing is now available for conformance to the CCM algorithm.
    • CCM will only be recognized on new FIPS 140-2 validations as FIPS Approved when referenced to an algorithm certificate.
    • All references to CCM on FIPS 140-2 validation certificates will have CCM certificates and will be referenced as CCM (Cert. nnn).

The transition period ends December 1, 2004. New FIPS 140-2 validations or re-validation test reports (RE: FIPS 140-2 IG G.8) received from CMT Laboratories after the transition period must conform to the new algorithm testing schemes indicated above and meet ALL current standards and IGs.
For algorithm validation requests where a CMT Laboratory has used CAVS3.3 to create files and has already sent the sample and request files to the vendor, NIST will accept validations using the old tools during the transition period. The CMT Laboratory should contact those vendors to inform them that the algorithm validation files supplied to them will expire at the end of the transition period. If the vendor has not returned the response files by that time, the request and sample files will have to be regenerated by the CAVS4.0 tool and the vendor will have to regenerate the response files. The CMVP will also review special conditions on a case-by-case basis.
[06-14-2004] New release of the CAVS algorithm validation testing tool to the CMT Laboratories (CAVS 3.3)
  • Added Key Generation to RSA X9.31.
  • Added validation tests for the General Purpose RNG specified in FIPS 186-2 Change Notice.
  • Added the ability to select more than one SHA when running validation tests for RSA. This has changed the format of the Signature Generation and Signature Verification files.
[03-11-2004] New release of the CAVS algorithm validation testing tool to the CMT Laboratories
New and Updated Implementation Guidance:
  • New rDSA algorithm testing
    • Testing is now available for conformance to several versions of the rDSA algorithm.
    • During the transition period, rDSA algorithms will continue to be recognized as FIPS Approved "vendor affirmed" or referenced to the new algorithm certificate if available for FIPS 140-2 validations. After the transition period, rDSA will only be recognized on new FIPS 140-2 validations as FIPS Approved when referenced to an algorithm certificate.
    • All references to RSA on FIPS 140-2 validation certificates that have rDSA certificates will be referenced as rDSA (Cert. nnn).
  • Expanded SHS algorithm testing
    • Testing is now available for conformance to SHA-1, SHA-256, SHA-384, and SHA-512 algorithms.
    • SHS algorithms will only be recognized as FIPS Approved with reference to an algorithm certificate.
    • All references to Secure Hash Algorithms on FIPS 140-2 validation certificates that have SHS certificates will be referenced as SHS (Cert. nnn).
  • New RNG algorithm testing
    • Testing is now available for conformance to the RNG algorithms that are referenced in FIPS 140-2 Annex C.
    • During the transition period, FIPS Approved RNG's found in FIPS 140-2 Annex C that do not have an algorithm certificate can still be used in FIPS Approved mode and will not be listed on the FIPS 140-2 validation certificate. They will only be listed on the FIPS 140-2 validation certificate if an algorithm certificate is available. After the transition period, FIPS Approved algorithms that can be tested can only be used in a FIPS Approved mode with reference to an algorithm certificate. Where testing is not available for the FIPS Approved algorithms, they will be annotated as "vendor affirmed".
    • All references to RNG algorithms on FIPS 140-2 validation certificates will be referenced as RNG (Cert. nnn).

The transition period ends June 04, 2004. New FIPS 140-2 validations or re-validation test reports (RE: FIPS 140-2 IG G.8) received from CMT Laboratories after the transition period must conform to the new algorithm testing schemes indicated above and meet ALL current standards and IGs.
For algorithm validation requests where a CMT Laboratory has used CAVS1.3 or DSSVS to create files and has already sent the sample and request files to the vendor, NIST will accept validations using the old tools during the transition period. The CMT Laboratory should contact those vendors to inform them that the algorithm validation files supplied to them will expire at the end of the transition period. If the vendor has not returned the response files by that time, the request and sample files will have to be regenerated by the CAVS3.0 tool and the vendor will have to regenerate the response files. The CMVP will also review special conditions on a case-by-case basis.