Cryptographic Algorithm Validation Program CAVP

[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:

1. Minor correction to KAS ECC screen - corrected the wording on the screen - min of h should be max of h
2. Minor correction to KAS ECC testing - corrected the length of a field which was causing KAS EEC testing to exit abnormally
3. In the TestedInfo.txt file, added prerequisite of RNG to GCM if option 2 is selected
4. In the TestedInfo.txt file, added statement for CMAC to ask for the prerequisite of TDES and/or AES, if applicable.
5. Modified the SHA screen to allow the indication of "null string not supported".
6. 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.