Announcements

[02-21-13] -- New release of the CAVS algorithm validation testing tool to the CST Laboratories (CAVS14.3). This version of the CAVS tool addresses minor updates:

1. - Corrected RSA summary file to correctly handle values from KeyGen 3.3 fixed key.
2. - Added FIPS 180-4 truncated SHA functions SHA-512/224 and SHA-512/256 to the Hash_DRBG, HMAC_DRBG, and Dual_EC_DRBG tests.
3. - Changed order that DRBG mechanism functions are called in tests when Prediction Resistance = False Old order: 1. Instantiate DRBG 2. Generate Random Bits (do not print) 3. Reseed 4. Generate Random Bits (print) 5. Uninstantiate New Order: 1. Instantiate DRBG 2. Reseed 3. Generate Random Bits (do not print) 4. Generate Random Bits (print) 5. Uninstantiate The order is unchanged for Prediction Resistance = False.

The transition period ends May 21, 2013.

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-90A, Key Agreement Scheme (KAS) FFC, KAS ECC, GCM 800-38D, FIPS186-3 DSA, FIPS186-3ECDSA, FIPS186-3RSA, XTS, the ECC DLC Primitive Component, SP800-108 KDF, the KDFs in SP800-135, SHA 512/224, SHA 512/256, HMAC with SHA 512/224, HMAC with SHA 512/256, RSA Signature Generation Component testing for PKCS1.5 and/or PKCS PSS, and/or the ECDSA2 Signature Generation Component, the CST lab must use the CAVS 14.3 to validate the IUT.
2. For any algorithm validation request where a lab has used a version of CAVS prior to CAVS 14.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 May 21, 2013.
3. If there are any validation requests where a lab has used a version of CAVS prior to CAVS 14.3 to create files and has not yet sent the appropriate files to the vendor, please regenerate everything using CAVS 14.3.

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

---

[12-18-12] -- New release of the CAVS algorithm validation testing tool to the CST Laboratories (CAVS14.2). This version of the CAVS tool addresses minor updates:

1. KAS ECCCDH Primitive Component: Modified code that creates txt file for website to include IUT's private key in the file.
2. KAS ECCCDH Primitive Component: ECCCDH Primitive Verify was erroneously requiring SHA as a prerequisite. ECCCDH Primitive Compoent testing does not require any prerequisites. This has been corrected.
3. KASECC: Changed the IDD-KASPREREQUISITESECC screen. Indicates that ECDSA PKV is not needed for Public Key Generation. Also added ECCCDH Primitive prerequisite guidance. This did not require any code change. It is only text.
4. HMAC: The key size boxes expecting values less than or greater than the block size would erroneously allow the block size. This has been corrected. It caused problems with the summary file.
5. HMAC: In CheckMO changed 5 to NUM_HMAC_TESTS to account for the addition of the 2 new SHAs.
6. HMAC: In CheckMO code for SHA512/256, there were some SHA224 labels that needed to be SHA256 and some indexes of 1 that needed to be 6.
7. AES: Counter Mode - if internal counter is specified, description is required. The CAVS screen didn't force this restriction. It now requires a description other than "" or "n/a" if internal counter is selected.
8. AES - Corrected bug to allow any forward cipher function to be used as prerequisite for AES Counter.
9. RSA2 info in inf file: There were 4 lines that had 2 equal signs. These have been replace with 1 equal sign.
10. RSA2VS document - More descriptive text explaining the requirements for each Key Generation option.
11. TDES error. If generate tests for encrypt and then check for encrypt and decrypt, it would indicate in the log file that the decrypt files didn't exist. But in the Summary file, it would indicate everything passed successfully. And visa versa. The Summary file has been changed to reflect the error.
12. CMAC - In inf file, this line: CMACVer_AES=False was in two places, before CMACVer_AES128=False and before CMACVer_AES192=False. The second occurance has been removed. This line only occurs at the begining of the CMACVer section.

The transition period ends March 18, 2013.

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-90A, Key Agreement Scheme (KAS) FFC, KAS ECC, GCM 800-38D, FIPS186-3 DSA, FIPS186-3ECDSA, FIPS186-3RSA, XTS, the ECC DLC Primitive Component, SP800-108 KDF, the KDFs in SP800-135, SHA 512/224, SHA 512/256, HMAC with SHA 512/224, HMAC with SHA 512/256, RSA Signature Generation Component testing for PKCS1.5 and/or PKCS PSS, and/or the ECDSA2 Signature Generation Component, the CST lab must use the CAVS 14.2 to validate the IUT.
2. For any algorithm validation request where a lab has used a version of CAVS prior to CAVS 14.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 March 18, 2013.
3. If there are any validation requests where a lab has used a version of CAVS prior to CAVS 14.2 to create files and has not yet sent the appropriate files to the vendor, please regenerate everything using CAVS 14.2.

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

---

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

1. Fixed bug in ECDSA2 pre-requisites for Key Pair Generation and Signature Generation to allow either DRBG or RNG instead of DRBG only.
2. Changed format of CAVS-generated input 'K' in SP 800-135 SSH KDF testing. 'K' is now represented as an mpint, where the first four octets (bytes) are a length field. 'K' now matches format in the SSH RFCs.
3. Fixed bug in HMAC key size lengths for HMAC SHA-512/224 and HMAC SHA-512/256.
4. SNMP KDF second Engine ID field now automatically populated with same value as first Engine ID if second is left blank or is of invalid length.
5. Fixed bug in RSA2 PKCS PSS Signature Generation Component testing.
6. Added COUNT variable to RSA2 PKCS1.5 Signature Generation Component test files.
7. Fixed bug in RSA2 Summary file for Component testing.
8. Increased number of trials from 10 to 30 on the RSA2PKCS1.5 and PSS Signature Generation Component validation tests.
9. Increased number of trials for all KDFs in SP800-135.
10. Fixed minor bug in KAS. One of the sample files indicated MACData = ?. But during verify, CAVS was looking for MacData = (Note difference in label.)

The transition period ends January 2, 2013.

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-90A, Key Agreement Scheme (KAS) FFC, KAS ECC, GCM 800-38D, FIPS186-3 DSA, FIPS186-3ECDSA, FIPS186-3RSA, XTS, the ECC DLC Primitive Component, SP800-108 KDF, the KDFs in SP800-135, SHA 512/224, SHA 512/256, HMAC with SHA 512/224, HMAC with SHA 512/256, RSA Signature Generation Component testing for PKCS1.5 and/or PKCS PSS, and/or the ECDSA2 Signature Generation Component, the CST lab must use the CAVS 14.1 to validate the IUT.
2. For any algorithm validation request where a lab has used a version of CAVS prior to CAVS 14.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 January 2, 2013.
3. If there are any validation requests where a lab has used a version of CAVS prior to CAVS 14.1 to create files and has not yet sent the appropriate files to the vendor, please regenerate everything using CAVS 14.1.

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

---

[08-28-12] -- Changed second bullet on CAVS 14.0 release instructions listed below for [08-20-12]. For any GCM/GMAC implementation validation request that doesn’t currently have a validation number assigned to it, where a lab has used a version of CAVS prior to CAVS 14.0 to create files, regardless if the values have been sent to the vendor or not, please regenerate the GCM/GMAC tests using CAVS 14.0 or CAVS12.2 following the instructions supplied to the laboratories. Additional information from the vender regarding the Plaintext and AAD lengths supported by the IUT will be required to complete the testing.

---

[08-20-12] -- New release of the CAVS algorithm validation testing tool to the CST Laboratories (CAVS14.0). This version of the CAVS tool addresses:

1. Added validation testing for SHA-512/224 and SHA-512/256 as defined in FIPS 180-4
2. Added validation testing for HMAC SHA-512/224 and HMAC SHA-512/256
3. Added component testing for RSA Signature Generation primitive: a. for PKCS1.5. This tests the RSASP1 primitive function described in PKCS #1 v2.1: RSA Cryptography Standard (June 14, 2002) Section 5.2.1. This test uses the encoded message EM format used by PKCS1.5. b. for PKCS PSS. This tests the RSASP1 primitive function described in PKCS #1 v2.1: RSA Cryptography Standard (June 14, 2002) Section 5.2.1. This test uses the encoded message EM format used by PKCS PSS
4. Added component testing for ECDSA2 Signature Generation primitive. This bypasses the hashing of the message by sending the hash value as the message
5. Fixed bug in GCM pre-requisites. RNG/DRBG is only required if IV is generated internally using method in Section 8.2.2, "RBG-based Construction."
6. Changed minimum allowed generated keying data length for ANS X9.63-2005 KDF from 112 bits to any length greater than 0.
7. Modified GCM screen to require values of Plaintext and AAD lengths to be tested for zero-length (if supported by the IUT), values that are a multiple of 128 (if supported by the IUT), and values that are a non-multiple of 128 (if supported by the IUT)
8. Fixed bug in inf file where KAS ECC NOKC KASECC__NOKC_EE_HMACSHA512=False when it should have =True. This only affected the inf file for automation. It did not affect the CAVS tool.
9. Changed name of tab on KAS_ECC for the component testing from "800-56A Component Testing" to "Sect 5.7.1.2 ECC CDH Component Testing" to be more exact
10. Enforce prerequisite of ECDSA Key Pair for ECCCDH Primitive Component testing. This prerequisite is required only if the Key Pair Generation option is selected on the "Select Functions Included in IUT..." button.
11. Made changes to Cover letter information including: Division number changed to 773, Institute was spelled wrong in return address, Added Laboratory Name to first sentence, and at end of letter indicated "posted on Nfiles"...

The transition period ends November 20, 2012.

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-90A, Key Agreement Scheme (KAS) FFC, KAS ECC, GCM 800-38D, FIPS186-3 DSA, FIPS186-3ECDSA, FIPS186-3RSA, XTS, the ECC DLC Primitive Component, SP800-108 KDF, the KDFs in SP800-135, SHA 512/224, SHA 512/256, HMAC with SHA 512/224, HMAC with SHA 512/256, RSA Signature Generation Component testing for PKCS1.5 and/or PKCS PSS, and/or the ECDSA2 Signature Generation Component, the CST lab must use the CAVS 14.0 to validate the IUT.
2. For any GCM/GMAC implementation validation request that doesn’t currently have a validation number assigned to it, where a lab has used a version of CAVS prior to CAVS 14.0 to create files, regardless if the values have been sent to the vendor or not, please regenerate the GCM/GMAC tests using CAVS 14.0. Additional information from the vender regarding the Plaintext and AAD lengths supported by the IUT will be required to complete the information on the screen.
3. For any algorithm validation request where a lab has used a version of CAVS prior to CAVS 14.0 to create files and has already sent the sample and request files to the vendor, except in the case of GCM/GMAC (see 2 above), NIST will accept validations using this tool up through November 20, 2012.
4. If there are any validation requests where a lab has used a version of CAVS prior to CAVS 14.0 to create files and has not yet sent the appropriate files to the vendor, please regenerate everything using CAVS 14.0.

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

---

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

1. Minor fix in HMAC Summary file.

The transition period ends August 30, 2012.

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, the testing of the ECC DLC Primitive Component, SP800-108 KDF and/or the individual KDFs in SP800-135, the CST lab must use the CAVS 12.2 to validate the IUT.
2. For any algorithm validation request where a lab has used a version of CAVS prior to CAVS 12.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 30, 2012.
3. If there are any validation requests where a lab has used a version of CAVS prior to CAVS 12.2 to create files and has not yet sent the appropriate files to the vendor, please regenerate everything using CAVS 12.2.

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

---

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

1. Corrected the displaying of the RSA2 Key Gen Summary file.<\p>
2. Corrected the displaying of the DRBG and RNG prerequisites in the RSA and RSA2 cover pages.
3. Added line to the RSA2 information in the inf file: Selected=False/True.
4. Changed name of variables for 800-108 in inf file to contain KDF108_ prefix.
5. Removed duplicate KDF_PipelineMode = True/False line in the inf file.
6. Changed section header from 800-108KDF to KDF800_108.
7. Added error checking to RSA Key Gen to handle when response file doesn't have all prime methods in file that are to be tested.
8. Fixed problems with SP 800-135 KDF input parameter limits.
9. Fixed error with DRBG input lengths that are not a multiple of 8 bits.
10. Changed default nonce length to zero for CTR_DRBG with no derivation function (df). Nonce is not used.

The transition period ends August 22, 2012.

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, the testing of the ECC DLC Primitive Component, SP800-108 KDF and/or the individual KDFs in SP800-135, the CST lab must use the CAVS 12.1 to validate the IUT.
2. For any algorithm validation request where a lab has used a version of CAVS prior to CAVS 12.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 August 22, 2012.
3. If there are any validation requests where a lab has used a version of CAVS prior to CAVS 12.1 to create files and has not yet sent the appropriate files to the vendor, please regenerate everything using CAVS 12.1.

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

---

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

1. Added validation testing for SP 800-108,
2. Added component validation testing for the Key Derivation Functions included in SP 800-135,
3. Fixed bug in name of file for files created for “All of 800-56A EXCEPT KDF” testing. An additional dash was in the file name between the scheme name and NOKC,
4. For DSA2 domain parameter g, testing changed so that p, q, and domain_parameter_seed would only be generated by CAVS using a method that the IUT supports,
5. For DSA2 domain parameter g, testing changed so that p, q, and domain_parameter_seed would only be generated by CAVS using a method that the IUT supports,
6. KAS ECC and KAS FFC – if assurances were selected and then unselected, the check box indicating assurance selected would stay checked. This was changed in KASNoteTab to uncheck “assurance checked” if assurance was unselected after being selected,
7. RSA1 KeyGen not printing RNG and DRBG prerequisite numbers on Cover Page. They are in the inf file correctly. This has been changed to make RNG and DRBG prerequisite info display on Cover Page,
8. RSA2 KeyGen3.3. If only support fixed e value doesn’t do KAT test. The Generate works correctly. But the verify looks for the KAT test. This has been corrected. (If supports random e values, both KAT and other test is run. This works correctly. This difference has been updated in VS document as well and will be posted at time of CAVS release,
9. RSA2 SigGenPKCSPSS entries in inf file: There was a repeating saltlen for 3072sha1. This has been removed,
10. RSA2 inf fileentry changes: 4 lines have two = signs and there should be only one:
        a. RSA2_BothPC_TableC2==False change to RSA2_BothPC_TableC2=False
        b. RSA2_BothPC_TableC3==False change to RSA2_BothPC_TableC3=False
        c. RSA2_ProvPC_TableC2==False change to RSA2_ProvPC_TableC2=False
        d. RSA2_ProvPC_TableC3==False change to RSA2_ProvPC_TableC3=False
11. RSA2 SigGenPSS. For modsize = 1024 bits and SHA512 bits, the length of the salt shall be 0 <= sLen <=hLen-2. That is, the length of the salt shall be a number from 0 to 62 bytes. This has now been changed on the SigGenPSS screen and code,
12. For DRBG testing, the number of returned bits output by each generate call was changed from a fixed value of one output block length to a tester-selected length ranging from 1 to 32 (default = 4) output block lengths. This will exercise parts of some implementations not covered by previous tests and enable testing for other implementations that do not support generating a single output block per call to generate.

The transition period ends June 23, 2012.

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, the testing of the ECC DLC Primitive Component, SP800-108 KDF and/or the individual KDFs in SP800-135, the CST lab must use the CAVS 12.0 to validate the IUT.
2. For any algorithm validation request where a lab has used a version of CAVS prior to CAVS 12.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 23, 2012.
3. If there are any validation requests where a lab has used a version of CAVS prior to CAVS 12.0 to create files and has not yet sent the appropriate files to the vendor, please regenerate everything using CAVS 12.0.

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

---

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

---

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