Announcements

[03-16-17]--New release of the CAVS algorithm validation testing tool to the CST Laboratories (CAVS21.3). The following modifications have been made:

1. ECDSA2 – In inf file, if SigGenComponent = TRUE also put SigGen = TRUE. Changed inf file to only have SigGen=true when AllSigGenTested=true.
2. XPN decrypt files – In the decrypt test, one possible cause of not passing is IV changed. Erroneously the IV xor Salt was changed but the IV was not. This caused the error to be bypassed. This has been fixed.
3. In "Additional Testing Details" for New implementations, was not able to select "CST Lab reviewed test harness if developed by vendor or other". This has been corrected.

The transition period ends June 16, 2017. This means CAVS21.2 can be used up until June 16, 2017. After that, CAVS21.3 must be used.

As has been the policy in the past:

1. EFFECTIVE IMMEDIATELY on any new validation requests for implementations of TDES, AES, SHA, HMAC, CCM, CMAC, DRBG 800-90A, Key Agreement Scheme (KAS) FFC, KAS ECC, GCM 800-38D (including GMAC and XPN), FIPS186-4 DSA, FIPS186-4 ECDSA, FIPS186-4 RSA, XTS, the ECC DLC Primitive Component, SP800-108 KDF, the KDFs in SP800-135, RSA Signature Generation Component testing for PKCS1.5 and/or PKCS PSS, the ECDSA2 Signature Generation Component, the RSADP component, the SP 800-38F Key Wrapping and/or SHA-3 or SHAKE, the CST lab must use the CAVS21.1 to validate the IUT.
2. For algorithm validation requests for XPN implementations using a version of CAVS prior to CAVS 21.3, please regenerate files and resend to the vendor. This is because of one of the changes made in this version is to correct an issue in XPN.
3. 3. For algorithm validation requests for any other algorithm except XPN, where a lab has used a version of CAVS prior to CAVS 21.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 June 16, 2017.
4. 4. If there are any validation requests where a lab has used a version of CAVS that has not expired to create files and has not yet sent the appropriate files to the vendor, please regenerate everything using CAVS 21.3.

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

[01-30-17]--New release of the CAVS algorithm validation testing tool to the CST Laboratories (CAVS21.2). The following modifications have been made:

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

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

As has been the policy in the past:

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

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

[01-12-17]--New release of the CAVS algorithm validation testing tool to the CST Laboratories (CAVS21.1). The following modifications have been made:

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

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

As has been the policy in the past:

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

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

[01-05-17]--New release of the CAVS algorithm validation testing tool to the CST Laboratories (CAVS21.0). The following modifications have been made:

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

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

As has been the policy in the past:

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

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

[07-06-16]--Updated Triple DES sample files to remove encrypytion with keying option 2 and to correct the values for OFB-I Monte Carlo.

[07-06-16]--New release of the CAVS algorithm validation testing tool to the CST Laboratories (CAVS20.2). The following modifications have been made:

1. Corrected bug in TDES OFB-I Monte Carlo test.
2. KAS ECC values were reported for keys shorter than expected. Corrected.
3. KAS FFC Header “HMAC SHAs supported…” was missing ending ‘]’. Corrected.
4. KAS ECC Header when EE parameter set selected –“ [SHA(s) supported (Used in the KDF function): …” was missing ending ‘]’. Corrected.

The transition period ends October 6, 2016. This means CAVS20.1 can be use up until October 6, 2016. After that, CAVS20.2 must be used.

As has been the policy in the past:

1. EFFECTIVE IMMEDIATELY on any new validation requests for implementations of TDES, AES, SHA, HMAC, CCM, CMAC, DRBG 800-90A, Key Agreement Scheme (KAS) FFC, KAS ECC, GCM 800-38D (including GMAC and XPN), FIPS186-4 DSA, FIPS186-4 ECDSA, FIPS186-4 RSA, XTS, the ECC DLC Primitive Component, SP800-108 KDF, the KDFs in SP800-135, RSA Signature Generation Component testing for PKCS1.5 and/or PKCS PSS, the ECDSA2 Signature Generation Component, the RSADP component, the SP 800-38F Key Wrapping and/or SHA-3 or SHAKE, the CST lab must use the CAVS20.2 to validate the IUT.
2. For any algorithm validation request where a lab has used a version of CAVS prior to CAVS 20.2 to create files and has already sent the sample and request files to the vendor, NIST will accept validations of acceptable algorithms using this tool up through October 6, 2016.
3. If there are any validation requests where a lab has used a version of CAVS that has not expired to create files and has not yet sent the appropriate files to the vendor, please regenerate everything using CAVS 20.2.

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

[06-16-16]--Updated GCMVS document to include testing for XPN.

[06-16-16]--Updated XPN test vectors.

[06-15-16]--New release of the CAVS algorithm validation testing tool to the CST Laboratories (CAVS20.1). The following modifications have been made:

1. Modified testing for GCM-AES-XPN. The categorization of the salt has been modified. Salt will be treated like the IV – are salts generated internally or not.
2. KASECC – extraneous byte of zeros on front of P curve sizes < 521. This has been removed. (Was causing error in the validity test.)
3. HMAC summary file – was reporting fail when everything passes. This has been corrected
4. TDES encrypt only – was including KO2 test files. Since KO2 allowed for decrypt only, if encrypt only tested, shouldn’t have KO2 files. This has been corrected.
5. Corrected minor errors

The transition period ends September 15, 2016. This means CAVS20.0 can be use up until September 15, 2016. After that, CAVS20.1 must be used.

As has been the policy in the past:

1. EFFECTIVE IMMEDIATELY on any new validation requests for implementations of TDES, AES, SHA, HMAC, CCM, CMAC, DRBG 800-90A, Key Agreement Scheme (KAS) FFC, KAS ECC, GCM 800-38D (including GMAC and XPN), FIPS186-4 DSA, FIPS186-4 ECDSA, FIPS186-4 RSA, XTS, the ECC DLC Primitive Component, SP800-108 KDF, the KDFs in SP800-135, RSA Signature Generation Component testing for PKCS1.5 and/or PKCS PSS, the ECDSA2 Signature Generation Component, the RSADP component, the SP 800-38F Key Wrapping and/or SHA-3 or SHAKE, the CST lab must use the CAVS20.1 to validate the IUT.
2. For any algorithm validation request where a lab has used a version of CAVS prior to CAVS 20.1 to create files and has already sent the sample and request files to the vendor, NIST will accept validations of acceptable algorithms using this tool up through September 15, 2016.
3. If there are any validation requests where a lab has used a version of CAVS that has not expired to create files and has not yet sent the appropriate files to the vendor, please regenerate everything using CAVS 20.1.

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

[05-06-16]--New release of the CAVS algorithm validation testing tool to the CST Laboratories (CAVS20.0). The following modifications have been made:

1. Added GCM-AES-XPN testing
2. Added SHA-3 to HMAC

The transition period ends August 6, 2016. This means CAVS19.4 can be use up until August 6, 2016. After that, CAVS20.0 must be used.

As has been the policy in the past:

1. EFFECTIVE IMMEDIATELY on any new validation requests for implementations of TDES, AES, SHA, HMAC, CCM, CMAC, DRBG 800-90A, Key Agreement Scheme (KAS) FFC, KAS ECC, GCM 800-38D (including GMAC and XPN), FIPS186-4 DSA, FIPS186-4 ECDSA, FIPS186-4 RSA, XTS, the ECC DLC Primitive Component, SP800-108 KDF, the KDFs in SP800-135, RSA Signature Generation Component testing for PKCS1.5 and/or PKCS PSS, the ECDSA2 Signature Generation Component, the RSADP component, the SP 800-38F Key Wrapping and/or SHA-3 or SHAKE, the CST lab must use the CAVS20.0 to validate the IUT.
2. For any algorithm validation request where a lab has used a version of CAVS prior to CAVS 20.0 to create files and has already sent the sample and request files to the vendor, NIST will accept validations of acceptable algorithms using this tool up through August 6, 2016.
3. If there are any validation requests where a lab has used a version of CAVS that has not expired to create files and has not yet sent the appropriate files to the vendor, please regenerate everything using CAVS 20.0.

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

[04-12-16]--Updated Components webpage to indicate that the RSASP1 component test for PKCS1.5 and PKCS PSS is identical. This was modified in January2014, updated in the RSASP1VS document but not updated on the webpage.

[03-24-16]--New release of the CAVS algorithm validation testing tool to the CST Laboratories (CAVS19.4). The following modifications have been made:

1. Bug in KAS resulting in tool crash fixed.

The transition period ends June 24, 2016.

As has been the policy in the past:

1. EFFECTIVE IMMEDIATELY on any new validation requests for implementations of TDES, AES, SHA, HMAC, CCM, CMAC, DRBG 800-90A, Key Agreement Scheme (KAS) FFC, KAS ECC, GCM 800-38D, FIPS186-4 DSA, FIPS186-4 ECDSA, FIPS186-4 RSA, XTS, the ECC DLC Primitive Component, SP800-108 KDF, the KDFs in SP800-135, RSA Signature Generation Component testing for PKCS1.5 and/or PKCS PSS, the ECDSA2 Signature Generation Component, the RSADP component, the SP 800-38F Key Wrapping and/or SHA-3 or SHAKE, the CST lab must use the CAVS19.4 to validate the IUT.
2. For any algorithm validation request where a lab has used a version of CAVS prior to CAVS 19.4 to create files and has already sent the sample and request files to the vendor, NIST will accept validations of acceptable algorithms using this tool up through June 24, 2016.
3. For any algorithm validation request where a lab had tried to generate KAS values and couldn’t (because program would crash) with CAVS 19.3, please generate test files with CAVS 19.4. If other algorithms were be tested for this IUT and test files have been created for those other algorithms with CAVS 19.3, regardless of if they had already been sent to the vendor or not, NIST will accept validations of these other algorithms using this tool up through June 24, 2016. In summary, you can use values generated for CAVS 19.3 for all algorithms except KAS. For KAS implementations, please use CAVS19.4.<\li>
4. If there are any validation requests where a lab has used a version of CAVS that has not expired to create files and has not yet sent the appropriate files to the vendor, please regenerate everything using CAVS 19.4.

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

[03-18-16]--New release of the CAVS algorithm validation testing tool to the CST Laboratories (CAVS19.3). The following modifications have been made:

1. Changes to generation of ECC keys to handle short keys for ECC correctly.
2. Remove check box for don’t post. This isn’t allowed.
3. In RSA SigGenSig files, one of the header lines was missing a #. This has been added. It didn’t affect the testing. Only affected applications that expected all header lines to have #.

The transition period ends June 18, 2016.

As has been the policy in the past:

1. EFFECTIVE IMMEDIATELY on any new validation requests for implementations of TDES, AES, SHA, HMAC, CCM, CMAC, DRBG 800-90A, Key Agreement Scheme (KAS) FFC, KAS ECC, GCM 800-38D, FIPS186-4 DSA, FIPS186-4 ECDSA, FIPS186-4 RSA, XTS, the ECC DLC Primitive Component, SP800-108 KDF, the KDFs in SP800-135, RSA Signature Generation Component testing for PKCS1.5 and/or PKCS PSS, the ECDSA2 Signature Generation Component, the RSADP component, the SP 800-38F Key Wrapping and/or SHA-3 or SHAKE, the CST lab must use the CAVS19.3 to validate the IUT.
2. For any algorithm validation request where a lab has used a version of CAVS prior to CAVS 19.3 to create files and has already sent the sample and request files to the vendor, NIST will accept validations of acceptable algorithms using this tool up through June 18, 2016.
3. If there are any validation requests where a lab has used a version of CAVS that has not expired to create files and has not yet sent the appropriate files to the vendor, please regenerate everything using CAVS 19.3.

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

[03-04-16]--New release of the CAVS algorithm validation testing tool to the CST Laboratories (CAVS19.2). The following modifications have been made:

1. Fixed a bug in the SHA-3 verify when null value not supported. This has been corrected.

The transition period ends June 4, 2016.

As has been the policy in the past:

1. EFFECTIVE IMMEDIATELY on any new validation requests for implementations of TDES, AES, SHA, HMAC, CCM, CMAC, DRBG 800-90A, Key Agreement Scheme (KAS) FFC, KAS ECC, GCM 800-38D, FIPS186-4 DSA, FIPS186-4 ECDSA, FIPS186-4 RSA, XTS, the ECC DLC Primitive Component, SP800-108 KDF, the KDFs in SP800-135, RSA Signature Generation Component testing for PKCS1.5 and/or PKCS PSS, the ECDSA2 Signature Generation Component, the RSADP component, the SP 800-38F Key Wrapping and/or SHA-3 or SHAKE, the CST lab must use the CAVS19.2 to validate the IUT.
2. For any SHA-3 algorithm validation request (includes SHA-3 and SHAKE algorithms) where a lab has used CAVS19.0 or CAVS19.1 to create files, use CAVS19.2 to verify the results.
3. For any algorithm validation request where a lab has used a version of CAVS prior to CAVS 19.1 to create files and has already sent the sample and request files to the vendor, NIST will accept validations of acceptable algorithms using this tool up through June 4, 2016 with the exception of SHA-3 testing. (See 2 above.)
4. If there are any validation requests where a lab has used a version of CAVS that has not expired to create files and has not yet sent the appropriate files to the vendor, please regenerate everything using CAVS 19.2.

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

[02-23-16]--New release of the CAVS algorithm validation testing tool to the CST Laboratories (CAVS19.1). The following modifications have been made:

1. Fixed a bug in the SHAKE3 Variable Output Test Verification Function. It was calculating the last tested length incorrectly and therefore was unable to check its correctness. This has been corrected.

The transition period ends May 23, 2016.

As has been the policy in the past:

1. EFFECTIVE IMMEDIATELY on any new validation requests for implementations of TDES, AES, SHA, HMAC, CCM, CMAC, DRBG 800-90A, Key Agreement Scheme (KAS) FFC, KAS ECC, GCM 800-38D, FIPS186-4 DSA, FIPS186-4 ECDSA, FIPS186-4 RSA, XTS, the ECC DLC Primitive Component, SP800-108 KDF, the KDFs in SP800-135, RSA Signature Generation Component testing for PKCS1.5 and/or PKCS PSS, the ECDSA2 Signature Generation Component, the RSADP component, the SP 800-38F Key Wrapping and/or SHA-3 or SHAKE, the CST lab must use the CAVS19.1 to validate the IUT.
2. For any SHA-3 algorithm validation request (includes SHA-3 and SHAKE algorithms) where a lab has used CAVS19.0 to create files, use CAVS19.1 to verify the results.
3. For any algorithm validation request where a lab has used a version of CAVS prior to CAVS 19.0 to create files and has already sent the sample and request files to the vendor, NIST will accept validations of acceptable algorithms using this tool up through May 23, 2016 with the exception of SHA-3 testing. (See 2 above.)
4. If there are any validation requests where a lab has used a version of CAVS that has not expired to create files and has not yet sent the appropriate files to the vendor, please regenerate everything using CAVS 19.1.

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

[02-19-16]--CAVP Guidance on Adding Unique Identifier To Nfile Email

[02-17-16]--CAVP and CMVP Guidance on Enforcing Algorithm Testing Information

[01-29-16]--New release of the CAVS algorithm validation testing tool to the CST Laboratories (CAVS19.0). The following modifications have been made:

1. Added validation testing for SHA-3 and SHAKE algorithms as specified in FIPS 202 SHA-3 Standard: Permutation-Based Hash and Extendable-Output Functions dated August 2015.
2. CMAC Verify – Add 2-Key TDES back. It was removed by accident.
3. DSA2 – Note regarding Sig Ver and checkbox for PQG Ver appears on all tabs. Have them only appear in their respective screens.
4. SP800-108KDF – Remove RNG standards listed under “Indicate SPs used to generate K”.
5. CMAC – Block size (Full and/or Partial) of messages is determined by all six values entered for each key size. All six values weren’t considered previously.

The transition period ends April 29, 2016.

As has been the policy in the past:

1. EFFECTIVE IMMEDIATELY on any new validation requests for implementations of TDES, AES, SHA, HMAC, CCM, CMAC, DRBG 800-90A, Key Agreement Scheme (KAS) FFC, KAS ECC, GCM 800-38D, FIPS186-4 DSA, FIPS186-4 ECDSA, FIPS186-4 RSA, XTS, the ECC DLC Primitive Component, SP800-108 KDF, the KDFs in SP800-135, RSA Signature Generation Component testing for PKCS1.5 and/or PKCS PSS, the ECDSA2 Signature Generation Component, the RSADP component, the SP 800-38F Key Wrapping and/or SHA-3 or SHAKE, the CST lab must use the CAVS19.0 to validate the IUT.
2. For any algorithm validation request where a lab has used a version of CAVS prior to CAVS 19.0 to create files and has already sent the sample and request files to the vendor, NIST will accept validations of acceptable algorithms using this tool up through April 29, 2016.
3. If there are any validation requests where a lab has used a version of CAVS that has not expired to create files and has not yet sent the appropriate files to the vendor, please regenerate everything using CAVS 19.0.

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

[01-04-16]--Updated webpages to reflect 2016 Transitions (see SP800-131A Revision 1).

[01-04-16]--Updated CAVP FAQ.

[12-29-15]--New release of the CAVS algorithm validation testing tool to the CST Laboratories (CAVS18.0). Contains changes to the testable functions in some of the approved cryptographic algorithms to reflect the transition to the use of stronger cryptographic keys and more robust algorithms (as recommended in NIST SP800-131A Revision 1 Transitions: Recommendation for Transitioning the Use of Cryptographic Algorithms and Key Lengths) effective January 1, 2016. It also includes several corrections to existing bugs. The following changes have been made :

6. SP800-131A Revision 1 - Transitions
   • a. Remove RNG tab
   • b. Remove TDES KO2 Encrypt from all modes
   • c. Remove CMAC - TDES KO2 from encrypt screen
   • d. Remove KBKDF - CMAC 2Key TDES from all modes
   • e. Remove all RNG prerequisites
7. DSA2, ECDSA2 and RSA2 - Remove affirmation of Generation with SHA1 used for protocol.  This is out of scope at this level (as discussed at 2015 CAVP/CMVP Manager’s meeting).
8. ECDSA2 – Initialized all prerequisites; was putting random numbers in prerequisite validation numbers
9. RSA2 Key Generation – changed code so processing for Random Prime – RandPrim - test has different error checking than the rest of the prime tests.
10. RSA2 Key Generation – Fixed operations of OK, Cancel and Deactivate and how they are listed in the inf file. They were being incorrectly reported in the inf file.
11. RSA2 Key Generation using Probable Primes wasn’t creating files if old or new format wasn’t checked. Old or new format shouldn’t have to be checked for probable prime files to be created. This has been fixed.
12. RSADP – Corrected error in Summary File – Was saying failed when it passed.
13. RSADP – Assure the CT value generated by CAVS is the length of the mod.
14. KAS FFC – when Full Val selected, shouldn’t ask for prerequisite of DSA. This has been corrected.
15. KAS ECC - Fixed bug in MACdata when P-521 produces short key values (AssignKCValue function). When it concatenated all the fields together, it was putting an erroneous value in the beginning byte of the ephem pub key.
16. KAS ECCCDH component doesn’t require any prerequisites unless functions Key Pair Generation or Re-generation are included in the IUT. Then ECDSA Key Pair Generation is a prerequisite. It was erroneously asking for SHA and DRBG. This has been corrected in CAVS.
17. GCM screen – Values entered on screen are saved when select Save. If there is an error in a value (for example, if value entered is not a multiple of 8) it was erasing everything from this value on. Now it is not checking the accuracy of the values until Generate GCM is selected.
18. GCM error message – made more descriptive.

The transition period ends March 29, 2016.

As has been the policy in the past:

1. EFFECTIVE IMMEDIATELY on any new validation requests for implementations of TDES, AES, SHA, HMAC, CCM, CMAC, DRBG 800-90A, Key Agreement Scheme (KAS) FFC, KAS ECC, GCM 800-38D, FIPS186-4 DSA, FIPS186-4 ECDSA, FIPS186-4 RSA, XTS, the ECC DLC Primitive Component, SP800-108 KDF, the KDFs in SP800-135, RSA Signature Generation Component testing for PKCS1.5 and/or PKCS PSS, the ECDSA2 Signature Generation Component, the RSADP component and/or SP 800-38F Key Wrapping, the CST lab must use the CAVS18.0 to validate the IUT.
(Note: The RNG algorithm has been removed from this list because SP800-131A Revision 1 states that the RNG algorithm is non-compliant beginning January 1, 2016. In the rare situation where an RNG implementation is to be validated between December 29, 2015 and January 1, 2016 and values have not been generated, CAVS17.9 may be used to generate them. If the validation is submitted before January 1, 2016 and it successfully passes the validation tests, this implementation will receive an RNG validation on the Historical RNG Validation List but it will be non-compliant. RNG validations will not be accepted after December 31, 2015.)
2. For any algorithm validation request where a lab has used a version of CAVS prior to CAVS 18.0 to create files and has already sent the sample and request files to the vendor, NIST will accept validations of acceptable algorithms using this tool up through March 29, 2016. If an IUT validated with CAVS 17.9 contains any of the above disallowed features as of December 31, 2015, these disallowed features will not be accepted. If the validation date is before January 1, 2016, the RNG validation will appear on the Historical RNG Validation List but it will be non-compliant.
3. If there are any validation requests where a lab has used a version of CAVS that has not expired to create files and has not yet sent the appropriate files to the vendor, please regenerate everything using CAVS 18.0.

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

[12-02-15]--Redesign of CAVP Website.

[09-30-15]--New release of the CAVS algorithm validation testing tool to the CST Laboratories (CAVS17.9). The following modifications have been made:

19. In RSADP, initialized testallconditions to TRUE.
20. Removed Dual ECDRBG.
21. Re-added testing for SHA1 for all digital signatures using SHA-1 for use with protocols.
22. Added affirmation check box required by IUT to assure that SHA1 with digital signature is being used for protocol use only. Also specified that these are protocols as specified by NIST protocol-specific guidance.
23. For HMAC-SHA256, when a MAC size of ‘24 Bytes’ was selected in the HMAC tab the ‘TestedInfo.txt’ file shows a MAC size of ‘26 Bytes’ instead. This typo has been fixed.
24. For RSA2 FIPS 186-2 - Legacy PKCS PSS Signature Verification: the “Salt Value=” line header was not being printed. The value was printed though on the same line as the salt length. (If the salt value was NULL, a zero was being adhered on the end of the salt length making it look like the salt length was multiplied by 10. (16 became 160) ) This has been corrected so it will look like this: Salt Length = 16. On next line it will say Salt Value = 0.
25. RSA2 FIPS 186-2 Key Gen testing – Was linked to “New Format code” so wouldn’t create files if New Format was not checked. New Format does not apply to FIPS 186-2 testing. This has been corrected to not need New Format checked. Only FIPS 186-2 Key Gen needs to be selected which brings up a window where information must be entered
26. Removed box around RSA mod 4096 as only allowed for revalidations because update to FPS 186-4 in future is going to put an explicit statement in these standards about allowing longer keys

The transition period ends December 30, 2015.

As has been the policy in the past:

1. EFFECTIVE IMMEDIATELY on any new validation requests for implementations of TDES, AES, SHA, RNG, HMAC, CCM, CMAC, DRBG 800-90A, Key Agreement Scheme (KAS) FFC, KAS ECC, GCM 800-38D, FIPS186-4 DSA, FIPS186-4 ECDSA, FIPS186-4 RSA, XTS, the ECC DLC Primitive Component, SP800-108 KDF, the KDFs in SP800-135, RSA Signature Generation Component testing for PKCS1.5 and/or PKCS PSS, the ECDSA2 Signature Generation Component, the RSADP component and/or SP 800-38F Key Wrapping, the CST lab must use the CAVS17.8 to validate the IUT.
2. For any algorithm validation request where a lab has used CAVS 17.8 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 30, 2015.
3. If there are any validation requests where a lab has used a version of CAVS that has not expired to create files and has not yet sent the appropriate files to the vendor, please regenerate everything using CAVS 17.9.

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

[09-16-15] -- Updated ASKDFVS document.

[06-16-15] -- Removed statement "This requirement must be enforced at the module or product level." from TDES testing announcement posted 06-04-15. The statement should read "As always, even though guidance included in a NIST publication is not testable at the algorithm level, this does not mean it can be ignored."

[06-16-15]--New release of the CAVS algorithm validation testing tool to the CST Laboratories (CAVS17.8). CAVS 17.7 WILL NOT BE USED BECAUSE OF A MINOR BUG FIX. The following modification has been made:

27. Fixed error associated with RSA2 Key Gen Format labels.

The transition period ends September 16, 2015.

As has been the policy in the past:

1. EFFECTIVE IMMEDIATELY on any new validation requests for implementations of TDES, AES, SHA, RNG, HMAC, CCM, CMAC, DRBG 800-90A, Key Agreement Scheme (KAS) FFC, KAS ECC, GCM 800-38D, FIPS186-4 DSA, FIPS186-4 ECDSA, FIPS186-4 RSA, XTS, the ECC DLC Primitive Component, SP800-108 KDF, the KDFs in SP800-135, RSA Signature Generation Component testing for PKCS1.5 and/or PKCS PSS, the ECDSA2 Signature Generation Component, the RSADP component and/or SP 800-38F Key Wrapping, the CST lab must use the CAVS17.8 to validate the IUT.
2. For any algorithm validation request where a lab has used CAVS 17.6 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 16, 2015.
3. For any algorithm validation request where a lab has used CAVS 17.7 to create files, please regenerate everything using CAVS 17.8.
4. If there are any validation requests where a lab has used a version of CAVS that has not expired to create files and has not yet sent the appropriate files to the vendor, please regenerate everything using CAVS 17.8.

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

[06-16-15]--New release of the CAVS algorithm validation testing tool to the CST Laboratories (CAVS17.7). The following modifications have been made:

28. RSA2 – Reports of non prime numbers were found in the CAVS test value files when all the numbers should have been prime. The reason was discovered and was corrected. It was caused by more than one error code being assigned to distinguish between different types of errors but only one error code (FAILURE) being processed.
29. RSA2 – Function C.9 has RSA_BAD800_90 error code if genRand800-90 fails. Changing this to FAILURE so only has one error code returned from Function C.9.
30. RSA2 – Added error message to be printed in fax file if PGENCOUNTERMAXFAIL occurs .
31. RSA2 – when any error happens restart the keygen process from the beginning. This is done by adding “while stat != SUCCESS continue” to SigVer931_gen and SigVerPKCS_PSS_gen.
32. RSA2 186-2 Key Gen – Summary file was not recognizing if only mod 2048 selected. This has been corrected.
33. RSA2 186-2 KeyGen – Fixed error in printing out Summary file. Caused when “fixed e” was selected.
34. ECDSA2 – If select SigGen and SigGenComponent check boxes, but then uncheck SigGen, when save it would recheck the SigGen button. This has been corrected.
35. ECDSA2 – The prerequisite numbers were being displayed as huge numbers. This has been corrected to display 0 until a value is entered.
36. RSA KeyGen – RSA2 186-4 KeyGen – Added the ability to test with either KeyGen format (the old format or the new format (See Announcement 7/10/14)) using the same CAVS tool.

The transition period ends September 16, 2015.

As has been the policy in the past:

1. EFFECTIVE IMMEDIATELY on any new validation requests for implementations of TDES, AES, SHA, RNG, HMAC, CCM, CMAC, DRBG 800-90A, Key Agreement Scheme (KAS) FFC, KAS ECC, GCM 800-38D, FIPS186-4 DSA, FIPS186-4 ECDSA, FIPS186-4 RSA, XTS, the ECC DLC Primitive Component, SP800-108 KDF, the KDFs in SP800-135, RSA Signature Generation Component testing for PKCS1.5 and/or PKCS PSS, the ECDSA2 Signature Generation Component, the RSADP component and/or SP 800-38F Key Wrapping, the CST lab must use the CAVS17.7 to validate the IUT.
2. For any algorithm validation request where a lab has used CAVS 17.6 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 16, 2015.
3. If there are any validation requests where a lab has used a version of CAVS that has not expired to create files and has not yet sent the appropriate files to the vendor, please regenerate everything using CAVS 17.7.

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

[06-04-15]--On February 5, 2015, guidance was posted indicating that there was going to be a change in the TDES algorithm validation testing to support the statement in NIST SP 800-67 Revision 1, dated January 2012 “A key bundle shall not consist of three identical keys.” Phase 1 of this guidance was completed and is included in CAVS 17.5 which was released March 4, 2015. This included

37. Removing the radio button to select Keying Option 3;
38. Modifying the Monte Carlo and MMT validation tests to remove the use of Keying Option 3 (where K1=K2=K3).

It has been determined that Phase 2 of this guidance posted on February 5, 2015 will not be done. The use of a key bundle consisting of three identical keys in the Known Answer tests is used to test the underlying DES engine(s) in a TDES implementation. The values used for the key and the text for the second and third rounds of the TDES function must be controlled to assure that the targeted components of the TDES algorithm are being tested. The Known Answer test values for TDES, which are based on the Known Answer test values designed initially for DES, assure this. Therefore an implementation must have the ability to use a key bundle consisting of three identical keys for validation testing purposes.

The requirement “A key bundle shall not consist of three identical keys.” is not testable at the algorithm level. As always, even though guidance included in a NIST publication is not testable at the algorithm level, this does not mean it can be ignored.

[05-14-15]--Updated FIPS 186-4 RSA Test Vectors to include truncated SHA examples.

[05-14-15]--Updated FIPS 186-4 ECDSA Test Vectors to include truncated SHA examples.

[05-14-15]--Updated CAVP Frequently Asked Questions (FAQ) document.

[03-16-15]--New release of the CAVS algorithm validation testing tool to the CST Laboratories (CAVS17.6). The following modifications have been made:

39. SP800-135 - The screens for IKEv1 and IKEv2 were too short to hold all the information and therefore the information was being truncated. The screen length has been increased to show all the information.

The transition period ends June 16, 2015.

As has been the policy in the past:

1. EFFECTIVE IMMEDIATELY on any new validation requests for implementations of TDES, AES, SHA, RNG, HMAC, CCM, CMAC, DRBG 800-90A, Key Agreement Scheme (KAS) FFC, KAS ECC, GCM 800-38D, FIPS186-4 DSA, FIPS186-4 ECDSA, FIPS186-4 RSA, XTS, the ECC DLC Primitive Component, SP800-108 KDF, the KDFs in SP800-135, RSA Signature Generation Component testing for PKCS1.5 and/or PKCS PSS, the ECDSA2 Signature Generation Component, the RSADP component and/or SP 800-38F Key Wrapping, the CST lab must use the CAVS17.6 to validate the IUT.
2. For any algorithm validation request where a lab has used CAVS 17.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 June 16, 2015.
3. If there are any validation requests where a lab has used a version of CAVS that has not expired to create files and has not yet sent the appropriate files to the vendor, please regenerate everything using CAVS 17.6.

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

[03-04-15] -- Modify TDES test vectors to remove Monte1 and MMT1 validation tests.

[03-04-15] -- Updated the SRTP section of The SP800-135 Validation System document.

[03-04-15]--New release of the CAVS algorithm validation testing tool to the CST Laboratories (CAVS17.5). The following modifications have been made:

40. New Information Added to Vendor/Implementation screen: This additional cryptographic algorithm testing information addresses how and by whom the algorithm testing was performed.
41. RSA2 – In the inf file the section for Legacy RSA information, the label had a space in the middle of it. The space has been removed. ( Legacy_PKCS#1_15SigVer had a space after it and before = or _mod or _SHA - ex. Legacy_PKCS#1_15SigVer _mod1024)
42. In GCM section of inf file – moved Selected=True/False to first line of section. Now consistent with other sections.
43. In GCM section – changed [AES GCM] to [GCM]. Code will accept both labels as input but will replace with only GCM for future. That way code will read older files created with other tool.
44. 800-135 SRTP – added ability to select subset of possible KDR values
45. 800-135 SRTP – wasn’t checking that 2^24 is supported when select all values. Corrected this
46. 800-135 SRTP – When verifying, assumed the given values from the request file were entered correctly so didn’t check their accuracy. I’ve changed this so it will detect differences between the given values and the values that should have been repeated exactly in the response file.
47. 800-135 SRTP – Modified Log file to be more descriptive.
48. ECDSA2 and ECDSA2SigGenComponent – In the inf file have these fields separated in the inf file since they get different validations (either ECDSA or Component). But when imported into the CAVS tool, they populate the same screen.
49. ECDSA2 SigGen verification of SHA512/224 and SHA512/256 – Was not verifying correctly – thought it was SHA224 and SHA256. This has been corrected.
50. TDES – Removed Keying Option 3 (K1=K2=K3) from the screens
51. TDES – Removed the Keying Option 3 Monte Carlo and MMT tests from the suite of tests for TDES.
52. RSA – Added Legacy tests to the TestInfo.txt file. They were not being printed on the cover letter.
53. RSA2 – Key Gen Screen. Make it clear that the Fixed/Random key selection on the first screen is for all methods except Appx B.3.3
54. RSA2 – Key Gen Screen. When 186-2 Key Generation was selected, was forcing either random or fixed public key in the 186-4 part of the screen to be selected. This is not required in 186-2 Key Generation – just erroneously required one option to be selected but never used. This has been corrected.

The transition period ends June 4, 2015.

As has been the policy in the past:

1. EFFECTIVE IMMEDIATELY on any new validation requests for implementations of TDES, AES, SHA, RNG, HMAC, CCM, CMAC, DRBG 800-90A, Key Agreement Scheme (KAS) FFC, KAS ECC, GCM 800-38D, FIPS186-4 DSA, FIPS186-4 ECDSA, FIPS186-4 RSA, XTS, the ECC DLC Primitive Component, SP800-108 KDF, the KDFs in SP800-135, RSA Signature Generation Component testing for PKCS1.5 and/or PKCS PSS, the ECDSA2 Signature Generation Component, the RSADP component and/or SP 800-38F Key Wrapping, the CST lab must use the CAVS17.5 to validate the IUT.
2. For any algorithm validation request where a lab has used CAVS 17.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 June 4, 2015.
3. If there are any validation requests where a lab has used a version of CAVS that has not expired to create files and has not yet sent the appropriate files to the vendor, please regenerate everything using CAVS 17.5.
4. For new algorithm validations tested with CAVS17.5, please begin supplying the additional information concerning how and by whom the algorithm testing was performed. A new form is generated by the CAVS17.5 tool called the (foldername)TestingMethodInfo.txt. This page of information will be signed by the appropriate individuals depending on whom and where the testing was performed, will be scanned in as a pdf (like you currently do the official submission cover letter) and will be included in the cryptographic algorithm validation submission.

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

[03-03-15]--Feedback from laboratories on the addition of this information can be found at Response from Labs for Collecting Testing Information.

[02-05-15] -- Change in TDES testing as of March 4, 2015 --NIST SP 800-67 Revision 1, dated January 2012 states in Section 3.1:

• A TDEA key ....A key bundle shall not consist of three identical keys.
55. Currently the TDES algorithm validation testing, as discussed in SP800-20, uses Keying Option 3 (where K1=K2=K3) when testing Keying Option 1 and Keying Option 2. This has been removed from the Monte Carlo and the MMT tests. The request files Monte1.req and MMT1.req (where K1=K2=K3) will no longer be generated by CAVS and therefore won't be used in the testing of TDES implementations. Monte2.req, Monte3.req, MMT2.req and MMT3.req will still be generated and used for testing.
56. Because the Keying Option 3 is used in the testing of CAVS, currently implementations need to have the ability to accept a key bundle consisting of three identical keys in addition to supporting Keying Option 1 and/or Keying Option 2.
57. Over the next 3 months (by June 2015), the CAVS testing will not allow TDES implementions to accept a key bundle consisting of three identical keys. Implementations supporting key bundles consisting of three identical keys will not pass the TDES cryptographic algorithm validation testing.(See 6/4/15 Announcement)
The CAVP will be updating the TDES testing in the CAVS tool in stages to phase out the use of Keying Option 3.
58. Phase 1 (In CAVS 17.5) (NOTE THESE DO NOT REQUIRE ANY CHANGE IN IMPLEMENTATION DESIGN):
59. Remove the radio button to select Keying Option 3
60. Modify the Monte Carlo and MMT validation tests to remove the use of Keying Option 3 (where K1=K2=K3) in the testing
61. Phase 2 (Within three months (June 2015)):
62. Add validation testing that will assure that the TDES implementation does not allow three identical keys to be used as input.
63. Modify the known answer tests to remove the use of three identical keys in the tests.(See 6/4/15 Announcement)

[01-23-15] -- Announced that the CAVP will be adding additional requirements to the vendor/implementation information page to record how and by whom the algorithm testing was performed for this IUT along with some additional testing details.  This will replace the current requirements of this information in the CMVP Cryptik tool.

[12-23-14] -- Updated SP800-56A Key Agreement Schemes (KAS) Test Vectors.

[12-8-14] -- CAVP request that CST Laboratories assure the accuracy of the vendor and implementation information given for cryptographic algorithm implementation validation requests; i.e., Vendor URL, etc.

[12-8-14] -- New release of the CAVS algorithm validation testing tool to the CST Laboratories (CAVS17.4). The following modifications have been made:

1. SP800-38F:  Error corrected in authenticatedDecryptionTest
2. SP800-135: IKEv2 minimum for nonces and payload should be 128 bits instead of 64 bits

The transition period ends March 8, 2015.

As has been the policy in the past:

1. EFFECTIVE IMMEDIATELY on any new validation requests for implementations of TDES, AES, SHA, RNG, HMAC, CCM, CMAC, DRBG 800-90A, Key Agreement Scheme (KAS) FFC, KAS ECC, GCM 800-38D, FIPS186-4 DSA, FIPS186-4 ECDSA, FIPS186-4 RSA, XTS, the ECC DLC Primitive Component, SP800-108 KDF, the KDFs in SP800-135, RSA Signature Generation Component testing for PKCS1.5 and/or PKCS PSS, the ECDSA2 Signature Generation Component, the RSADP component and/or SP 800-38F Key Wrapping, the CST lab must use the CAVS17.4 to validate the IUT.
2. For any algorithm validation request where a lab has used CAVS 17.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 March 8, 2015. 
3. If there are any validation requests where a lab has used a version of CAVS that has not expired to create files and has not yet sent the appropriate files to the vendor, please regenerate everything using CAVS 17.4.

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

[09-30-14] -- New release of the CAVS algorithm validation testing tool to the CST Laboratories (CAVS17.3). The following modifications have been made:

1. One of the AAD length fields was not being read correctly in the 'Verify' routine.
2. When both the Section 8.2.1 and Section 8.2.2 methods for generating the IV internally were checked, the cover letter only displayed one of them. It now displays both.
3. GCM screen – Initialization Vector section: Corrected sentence on screen to reflect the valid minimum length to 8. (Valid lengths: 8 bits to 1024 bits)
4. Key Wrap screen – AES Key Wrap (KW) Tested Plaintext Lengths section: Added clarification that the minimum value for an odd multiple of 64 is 64*3=192. (value >= 192)
5. Key Wrap screen – TDES Key Wrap (TKW) Tested Plaintext Lengths section:  Added clarification that the minimum value for an odd multiple of 32 is 32*3=96. (value >= 96)

The transition period ends December 30, 2014.

As has been the policy in the past:

1. EFFECTIVE IMMEDIATELY on any new validation requests for implementations of TDES, AES, SHA, RNG, HMAC, CCM, CMAC, DRBG 800-90A, Key Agreement Scheme (KAS) FFC, KAS ECC, GCM 800-38D, FIPS186-4 DSA, FIPS186-4 ECDSA, FIPS186-4 RSA, XTS, the ECC DLC Primitive Component, SP800-108 KDF, the KDFs in SP800-135, RSA Signature Generation Component testing for PKCS1.5 and/or PKCS PSS, the ECDSA2 Signature Generation Component, the RSADP component and/or SP 800-38F Key Wrapping, the CST lab must use the CAVS17.3 to validate the IUT.
2. For any algorithm validation request where a lab has used CAVS 17.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 December 30, 2014. 
3. If there are any validation requests where a lab has used a version of CAVS that has not expired to create files and has not yet sent the appropriate files to the vendor, please regenerate everything using CAVS 17.3.

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

[08-21-14] -- New release of the CAVS algorithm validation testing tool to the CST Laboratories (CAVS17.2). The following modifications have been made:

1. GCM test vector files – modified header to remove single quotes from around product folder name. This was causing the verification of the files to fail.

The transition period ends November 14, 2014.

As has been the policy in the past:

1. EFFECTIVE IMMEDIATELY on any new validation requests for implementations of TDES, AES, SHA, RNG, HMAC, CCM, CMAC, DRBG 800-90A, Key Agreement Scheme (KAS) FFC, KAS ECC, GCM 800-38D, FIPS186-4 DSA, FIPS186-4 ECDSA, FIPS186-4 RSA, XTS, the ECC DLC Primitive Component, SP800-108 KDF, the KDFs in SP800-135, RSA Signature Generation Component testing for PKCS1.5 and/or PKCS PSS, the ECDSA2 Signature Generation Component, the RSADP component and/or SP 800-38F Key Wrapping, the CST lab must use the CAVS17.2 to validate the IUT.
2. For any algorithm validation request where a lab has used CAVS 17.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 November 14, 2014.  (Note: CAVS 17.1 was released on August 14, 2014. Since the change to CAVS 17.2 is minor and since CAVS 17.1 has only been available for a week, the transition period for CAVS 17.1 will end on the same date as CAVS. Therefore, NIST will accept validations using CAVS 17.1 up through November 14, 2014, as stated above.)
3. If there are any validation requests where a lab has used a version of CAVS that has not expired to create files and has not yet sent the appropriate files to the vendor, please regenerate everything using CAVS 17.2.

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

[08-14-14] -- New release of the CAVS algorithm validation testing tool to the CST Laboratories (CAVS17.1). The following modifications have been made:

1. Key Wrap (NIST SP 800-38F) a. CAVS provides five fields for tested plaintext lengths. Previously, all five needed valid, nonzero values in order for the tests to run. However, conforming NIST SP 800-38F implementations do not need to set all five input lengths, only those that are supported b. indicate unused lengths by entering a 0 in the field
2. DRBG - for CTR_DRBG using derivation function (df). The derivation function only accepts bit strings that are a multiple of 8 bits long. Therefore, CAVS now restricts: * additional input length to multiple of 8 bits * sum of entropy input, nonce and personalization string lengths to 8 bits
3. SP800-108 – Was not handling zero values in the L fields correctly. This has been corrected by ignoring the zero values.
4. 186-2 RSA Signature Generation for PKCS-PSS mod size 2048, 3072 and 4096 (used for CMVP module revalidations requiring FIPS 186-2 RSA implementations to be tested) – CAVS will now allow salt lengths that don’t adhere to the 186-4 specifications as was allowed before 186-4 changed the specifications. THIS CAN ONLY BE USED FOR USE IN CMVP REVALIDATIONS.
5. Corrected RSA2’s REVALONLY section in inf file to = True only when something for FIPS186-2 is selected.
6. TDES – Changed the message displayed at the completion of verify TDES to indicate if the test passed or failed.
7. GCM test vector files – added header that mentions product folder name.
8. KDF-800-135 – Corrected the message displayed at the completion of Verify to indicate if it passed or failed.
9. HMAC screens – added information to identify that lengths are represented in bytes.

The transition period ends November 14, 2014.

As has been the policy in the past:

1. EFFECTIVE IMMEDIATELY on any new validation requests for implementations of TDES, AES, SHA, RNG, HMAC, CCM, CMAC, DRBG 800-90A, Key Agreement Scheme (KAS) FFC, KAS ECC, GCM 800-38D, FIPS186-4 DSA, FIPS186-4 ECDSA, FIPS186-4 RSA, XTS, the ECC DLC Primitive Component, SP800-108 KDF, the KDFs in SP800-135, RSA Signature Generation Component testing for PKCS1.5 and/or PKCS PSS, the ECDSA2 Signature Generation Component, the RSADP component and/or SP 800-38F Key Wrapping, the CST lab must use the CAVS17.1 to validate the IUT.
2. For any algorithm validation request where a lab has used 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 November 14, 2014. 
3. If there are any validation requests where a lab has used a version of CAVS that has not expired to create files and has not yet sent the appropriate files to the vendor, please regenerate everything using CAVS 17.1.

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

[07-10-14] -- The format of the FIPS 186-4 RSA Key Generation test was redesigned in March 2014. (For reference, the 2 formats are referred to as "the old format" and "the new format".) Beginning July 2014, the vendor may choose either format to test their 186-4 RSA Key Generation. Both formats are equivalent. The "old format" of the test provided some values to the IUT and the IUT used these values to calculate the required answers. The "new format" requires the IUT to supply all the values used for testing.

Both the old format of the FIPS 186-4 RSA Key Generation test and the new format of the FIPS 186-4 RSA Key Generation test provide the same level of testing for the FIPS 186-4 RSA Key Generation function. The CAVP has decided that the vendor can select either test for testing implementations of FIPS 186-4 RSA Key Generation.

The CAVP is allowing this because we recognize that the redesign of the Key Generation test may impact a vendor's design of their implementation. A vendor who has either already started the design of their implementation or who has tested their implementation once using the old formatted test and now wishes to test another version of the same implementation, may need to make modifications to their design in order to be able to run the new format of the validation test. This may require a non-trivial amount of effort and time leading to severe delays in the validation process. If the tests are equivalent, it is unnecessary to cause this issue.

[06-19-14] -- New release of the CAVS algorithm validation testing tool to the CST Laboratories (CAVS). The following modifications have been made:

1. Added validation testing for SP800-38F Recommendation for Block Cipher Modes of Operation: Methods for Key Wrapping.
2. Comment line of the RSA SigGen files contained “[mod = 4096]” string.  The square brackets are used to indicate a section in the file.  Since the square brackets used in the comment line are not the beginning of a file section, an error occurred.  Removed the square brackets from the comment line.
3. The RSA component check boxes were not being checked when the screen was called up after exiting CAVS and going back in.  Even though the information was correct in the inf file.  Corrected the program to populate the check boxes when restarting CAVS.
4. For SP800-56A Revision 2: Changed the minimum length restrictions for MACKey MAC Len for all MACs as specified in 5.2.1.
5. RSA Key Gen Summary file correctly indicated that each individual section of the test passed but erroneously indicated the summary of all tests failed.  This bug was introduced when adding mod 4096. It has been corrected.
6. ECDSA2 Summary file was indicating KeyGen failed but it passed 30 out of 30 for every curve.  This bug was introduced when adding FIPS186-2 Key Pair Generation option. Updated expected iterations to correct this error.
7. Changed format of inf file RSA2 to have separate section for all of REVALONLY tests instead of mixing this in each section.  Also put label REVALONLY_ at the beginning of each line. (Request for automation)
8. Added “REVALONLY_” label to front of ECDSA2 KeyPair_FIPS186_2 in inf file. (Request for automation)
9. Removed SigGen message “Note 186-2 SigGen Mod4096 Only for use in CMVP SUB report submission” from SigVer screens for X9.31 and PKCS1.5.  This screen is shared by these two functions and needed to be block from the SigVer screens.
10. RSADP – in inf file changed section to only have information for 2048 mod size.
11. GCM testing – increased maximum supported plaintext and AAD lengths from 1024 bits to 65536 bits.

The transition period ends Sept 19, 2014.

As has been the policy in the past:

1. EFFECTIVE IMMEDIATELY on any new validation requests for implementations of TDES, AES, SHA, RNG, HMAC, CCM, CMAC, DRBG 800-90A, Key Agreement Scheme (KAS) FFC, KAS ECC, GCM 800-38D, FIPS186-4 DSA, FIPS186-4 ECDSA, FIPS186-4 RSA, XTS, the ECC DLC Primitive Component, SP800-108 KDF, the KDFs in SP800-135, RSA Signature Generation Component testing for PKCS1.5 and/or PKCS PSS, the ECDSA2 Signature Generation Component, the RSADP component and/or SP 800-38F Key Wrapping, the CST lab must use the CAVS to validate the IUT.
2. For any algorithm validation request where a lab has used CAVS 16.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 September 19, 2014. 
3. If there are any validation requests where a lab has used a version of CAVS that has not expired to create files and has not yet sent the appropriate files to the vendor, please regenerate everything using CAVS .

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

[05-07-14] -- Updated CAVP Frequently Asked Questions (FAQ) document.

---

[04-23-14] -- New release of the CAVS algorithm validation testing tool to the CST Laboratories (CAVS16.3). The following modifications have been made:

1. Added additional error checking to RSA Key Gen to assure the input values supplied by the IUT are valid values (ex, odd integers if they are supposed to be, valid lengths based on Table B.1, etc.). Error messages will be printed to the logfile to indicate these errors.
2. Fixed bug in GCMTab.cpp.
3. In CAVS 16.2, when the 4096 column was added to the RSA SigGen screens, it also was being displayed in the SigVer screens. It shouldn’t be on the SigVer screens. Removed 4096 column in SigVer9.31 and SigVerPKCS1.5 screens.
4. For RSA Key Gen B3.3, added check box to indicate if supports fixed or random values for public key e.

The transition period ends July 23, 2014.

As has been the policy in the past:

1. EFFECTIVE IMMEDIATELY on any new validation requests for implementations of TDES, AES, SHA, RNG, HMAC, CCM, CMAC, DRBG 800-90A, Key Agreement Scheme (KAS) FFC, KAS ECC, GCM 800-38D, FIPS186-4 DSA, FIPS186-4 ECDSA, FIPS186-4 RSA, XTS, the ECC DLC Primitive Component, SP800-108 KDF, the KDFs in SP800-135, RSA Signature Generation Component testing for PKCS1.5 and/or PKCS PSS, the ECDSA2 Signature Generation Component and/or the RSADP component, the CST lab must use the CAVS16.3 to validate the IUT.
2. For any algorithm validation request where a lab has used CAVS 16.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 23, 2014.
3. 3. If there are any validation requests where a lab has used a version of CAVS that has not expired to create files and has not yet sent the appropriate files to the vendor, please regenerate everything using CAVS 16.3.

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

[04-01-14] -- New release of the CAVS algorithm validation testing tool to the CST Laboratories (CAVS16.2). The following additions, modifications and updates have been made:

1. ECDSA2 Summary File - Correction for error when Sig Gen not selected it didn't say "Not Configured".
2. Change labels in inf file for Legacy_FIPS186-2 entries: Change dash to underscore.
3. Added 186-2 RSA Signature Generation for 4096 to Sig Gen tabs to allow for use with CMVP 1SUB, 2SUB and 4SUB report submissions.
4. Added 186-2 RSA Key Generation to Key Gen tab to allow for use with CMVP 1SUB, 2SUB and 4SUB report submissions.
5. Removed a file name that was used for KAS debugging purposes. The file is named configvalues.txt and was being written to directory d . If the machine running CAVS didn’t have a drive d, an error was displayed. If the machine running CAVS did have a drive d, it created this file. Labs should look on their d drive (it they have one) and remove this file.
6. Removed three file names that were used for debugging purposes. They were written to d directory and can be deleted by labs if found on their machines. The file names are B35.txt (for RSA Key Gen testing), ecdsa2_verify.txt (for ECDSA testing), and ecdsa2_verify_component.txt (for ECDSA component testing ).
7. Fixed bug in CAVS Screen Status for DRBG. Before this fix, the status screen for DRBG would show that both Hash_DRBG and HMAC_DRBG were tested for a particular SHA function whenever either one (Hash_DRBG or HMAC_DRBG) was actually tested. Please note that the ‘Display Status’ feature has not been actively maintained for several versions and should not be used as an accurate indication of testing status.
8. Fixed bug in AES_GCM. A 0 (zero) in any of the Plaintext and AAD bit length fields is supposed to be interpreted as ‘not supported’; however, CAVS was interpreting them as a supported zero bit length. Zero-length Plaintext and AAD support is indicated by checking the checkbox labelled ‘Check if supports 0 length Plaintext (GMAC)’ or ‘Check if supports 0 length AAD”.

The transition period ends July 1, 2014.

As has been the policy in the past:

1. EFFECTIVE IMMEDIATELY on any new validation requests for implementations of TDES, AES, SHA, RNG, HMAC, CCM, CMAC, DRBG 800-90A, Key Agreement Scheme (KAS) FFC, KAS ECC, GCM 800-38D, FIPS186-4 DSA, FIPS186-4 ECDSA, FIPS186-4 RSA, XTS, the ECC DLC Primitive Component, SP800-108 KDF, the KDFs in SP800-135, RSA Signature Generation Component testing for PKCS1.5 and/or PKCS PSS, the ECDSA2 Signature Generation Component and/or the RSADP component, the CST lab must use the CAVS16.2 to validate the IUT.
2. For any algorithm validation request where a lab has used CAVS 16.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 1, 2014.
3. 3. If there are any validation requests where a lab has used a version of CAVS that has not expired to create files and has not yet sent the appropriate files to the vendor, please regenerate everything using CAVS 16.2.

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

[03-18-14] -- New release of the CAVS algorithm validation testing tool to the CST Laboratories (CAVS16.1). The following additions, modifications and updates have been made:

1. Fixed bugs in ECDSA2 Signature Generation Component test.
2. Removed note on RNG screen restricting its use because on 1/7/14, IG G.14 was updated removing the following text: “In the case of the deprecated RNGs, new algorithm or module validation submissions will only be accepted for validation by the CAVP or CMVP, respectively, through the end of 2013. However, modules submitted for revalidation under IG G.8, scenario 1 through 4 containing deprecated RNGs will be accepted for revalidation by the CMVP until their use is disallowed on Dec 31, 2105.”
3. Changed references of 186-3 to 186-4 in the RSANotes and RSAPrerequisite screens.
4. Started adding the changes for SP800-56A Revision 2. In FFC screens only, changed the minimum lengths allowed. (See Section 5.2.1 of SP 800-56A Revision 2)
5. Added labels to values displayed during KASECC verification for assistance when debugging IUT.
6. Fixed bugs in RSA Legacy Signature Verification: a. Names of files should be SigVer931_186-2.xxx instead of SigVerRSA_186-2.xxx b. Summary file correction
7. Changed RSA2 Key Generation tests. The IUT now supplies all the values for the Key Generation tests. The Fixed or Random public key parameter is no longer asked for or recorded on webpage because the IUT will supply the public keys that it can support.
8. Modified RSASP1 validation test to only test the RSASP1 component. Originally it was testing more than the RSASP1 component.
9. Added FIPS 186-2 Key Gen testing to ECDSA2 Key Pair tab for revalidation only.
10. Removed 1536 bit length from list of Diffie-Hellman shared secret lengths for testing IKE v1 and IKE v2 KDFs.
11. For DSA legacy domain parameter verification, CAVS generated PQGVer1862.fax in the sample file directory. The extension (.fax) was incorrect. Changed extension to .sam.

The transition period ends June 18, 2014.

As has been the policy in the past:

1. EFFECTIVE IMMEDIATELY on any new validation requests for implementations of TDES, AES, SHA, RNG, HMAC, CCM, CMAC, DRBG 800-90A, Key Agreement Scheme (KAS) FFC, KAS ECC, GCM 800-38D, FIPS186-4 DSA, FIPS186-4 ECDSA, FIPS186-4 RSA, XTS, the ECC DLC Primitive Component, SP800-108 KDF, the KDFs in SP800-135, RSA Signature Generation Component testing for PKCS1.5 and/or PKCS PSS, the ECDSA2 Signature Generation Component and/or the RSADP component, the CST lab must use the CAVS16.1 to validate the IUT.
2. For any algorithm validation request where a lab has used CAVS 16.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 18, 2014.
3. 3. If there are any validation requests where a lab has used a version of CAVS that has not expired (it's transition period is over) to create files and has not yet sent the appropriate files to the vendor, please regenerate everything using CAVS 16.1.

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

[12-12-13] -- New release of the CAVS algorithm validation testing tool to the CST Laboratories (CAVS16.0). contains changes to the testable functions in some of the approved cryptographic algorithms to reflect the transition to the use of stronger cryptographic keys and more robust algorithms (as recommended in NIST SP800-131A Transitions: Recommendation for Transitioning the Use of Cryptographic Algorithms and Key Lengths) effective January 1, 2014. The following changes have been made :

1. DSA (Refers to FIPS 186-2) – Removed DSA tab. PQG Generation, Key Pair Generation, and Signature Generation are disallowed after 2013 because IG G.15 states “After December 31, 2013, implementations of domain parameter generation, key pair generation and digital signature generation as specified in FIPS 186-2 will not be validated by the CAVP or CMVP.” PQG Verification and Signature Verification are still allowed for legacy use. The testing of these 186-2 functions has been moved to the DSA2 tab which refers to FIPS 186-4. (NOTE: FIPS 186-4 DSA can still be validated for all functions (See DSA2 Tab).)
2. RNG –IG G.15 states “ In the case of the deprecated RNGs, new algorithm or module validation submissions will only be accepted for validation by the CAVP or CMVP, respectively, through the end of 2013 . “ “However, modules submitted for revalidation under IG G.8, scenarios 1 through 4 containing deprecated RNGs will be accepted for revalidation by the CMVP until their use is disallowed on December 31, 2015 (see SP 800-131A).” In the case of revalidations, RNG validation may need to be performed. Therefore, RNG validation testing will remain in the CAVS tool but will only be allowed to validate RNG implementations in modules submitted for revalidation.
3. DSA2 (Refers to 186-4) – The following changes have been made: a. Because modulus sizes less than or equal to 80 bits of security are disallowed and SHA1 is disallowed for Digital Signature Generation after 2013: i. PQG Gen – Removed “L=1024 N=160” column ii. Key Pair – Removed “L=1024 N=160” column iii. Signature Generation 1. Removed “L=1024 N=160” column 2. Removed SHA1 from all modulus columns b. The PQG Verification selection under the DSA2 tab has been modified to add a checkbox to test FIPS186-2 PQG Verification as specified in FIPS 186-4 Annex A.1.1.1 Validation of the Probable Primes p and q that were Generated Using SHA-1 as Specified in Prior Versions of this Standard. c. A note has been added to the Signature Verification selection under the DSA2 tab explaining that Signature Verification as specified in FIPS 186-2 and FIPS 186-4 is the same and therefore the same screen can be used to test either version. Therefore, there is no distinction between the two when testing Signature Verification.
4. ECDSA2 (Refers to 186-4) - The following changes have been made: a. Because modulus sizes less than or equal to 80 bits of security are disallowed and SHA1 is disallowed for Digital Signature Generation after 2013: i. Key Pair – Removed P192 K163 B163 ii. Signature Generation 1. Removed the complete columns for P192 K163 and B163 2. Removed SHA1 from all curve columns b. Add documentation explaining PKV and Signature Verification for both 186-2 and 186-4 are the same. Therefore, there is no distinction between the two versions when testing these functions.
5. RSA (Refers to FIPS 186-2) - Removed RSA tab. PQG Generation, Key Pair Generation, and Signature Generation are disallowed after 2013 because IG G.15 states “After December 31, 2013, implementations of domain parameter generation, key pair generation and digital signature generation as specified in FIPS 186-2 will not be validated by the CAVP or CMVP. “ Signature Verification is still allowed for legacy use. The 186-2 RSA Validation Tests have been moved under the RSA2 tab. They can be accessed by checking the 186-2 Legacy Tests tab under the RSA2 tab. (NOTE: FIPS 186-4 RSA can still be validated (See RSA2 Tab).)
6. RSA2 (Refers to 186-4) – The following changes have been made: a. Because anything less than or equal to 80 bits of security is disallowed and SHA1 is disallowed for Digital Signature Generation after 2013: i. GenKey9.31 – Removed 1024 column only in B.3.4 (Provable Primes), B.3.5 (Provable and Probable Primes) and B.3.6 (Probable Primes), but kept SHA1. (1024 bit RSAs keys are not used for any other purpose but Signature Generation. Therefore they are removed. FIPS PUB 186-4 Section 4 states that SHA1 can be used for key generation because output length of 160 is bigger than 128 and 112 associated security string lengths of 2048 and 3072 bit moduli.) ii. Signature Generation 9.31, PKCS1.5 and PKCS PSS 1. Removed 1024 column 2. Removed SHA1 from modulus sizes 2048 and 3072 columns iii. RSA Component Test – Removed PKCS 1.5 SHA1 because SHA1 was removed from Mod 2048 b. Added new tab called 186-2 Legacy Tests. By selecting this tab, the FIPS 186-2 Signature Verification for 9.31, PKCS1.5 and PSS can be accessed.
7. ECDSA (Refers to FIPS 186-2) - – Removed ECDSA tab. PQG Generation, Key Pair Generation, and Signature Generation are disallowed after 2013 because IG G.15 states “After December 31, 2013, implementations of domain parameter generation, key pair generation and digital signature generation as specified in FIPS 186-2 will not be validated by the CAVP or CMVP. “ PKV and Signature Verifications are still allowed for legacy use. The testing of these 186-2 functions has been moved to the ECDSA2 tab. (NOTE: FIPS 186-4 ECDSA can still be validated (See ECDSA2 Tab).)
8. KASFFC – Removed FA parameter set because 80 bits security disallowed after 2013.
9. KASECC – Because anything less than or equal to 80 bits of security is disallowed after 2013: a. Removed EA parameter set b. ECCCDH Component test (Sec 5.7.1.2) – Removed P192 K163 and B163.
10. KDF 800-135 - – Because anything less than or equal to 80 bits of security is disallowed after 2013: a. IKE v1 – Removed 185, 192, 1024 from the 3 columns in the Diffie-Hellman Shared Secret section b. IKE v2 – Removed 185, 192, 1024 from the 3 columns in the Diffie-Hellman Shared Secret section c. ANS X9.63 – Removed 163 and 192 in both min and max fields d. SSH – Changed the Diffie-Hellman Shared Secret Lengths default value to 2048.
11. RSADP Component (from SP800-56B) – Removed 1024. Because only allow 2048 now, modified screen so only need to press RSADP Generate or RSADP Verify.
12. A minor bug was fixed in SP 800-135 to the shared secret length for IKEv1 and IKEv2.

The transition period ends March 12, 2014.

As has been the policy in the past:

1. EFFECTIVE IMMEDIATELY on any new validation requests for implementations of TDES, AES, SHA, RNG, HMAC, CCM, CMAC, DRBG 800-90A, Key Agreement Scheme (KAS) FFC, KAS ECC, GCM 800-38D, FIPS186-4 DSA, FIPS186-4 ECDSA, FIPS186-4 RSA, XTS, the ECC DLC Primitive Component, SP800-108 KDF, the KDFs in SP800-135, RSA Signature Generation Component testing for PKCS1.5 and/or PKCS PSS, the ECDSA2 Signature Generation Component and/or the RSADP component, the CST lab must use the CAVS 16.0 to validate the IUT.
2. 2. For any algorithm validation request where a lab has used a version of CAVS prior to CAVS 16.0 to create files and has already sent the sample and request files to the vendor, NIST will accept validations of acceptable algorithms and key lengths using this tool up through March 12, 2014. If an IUT validated with CAVS 15.2 contains key lengths, hash sizes, or algorithms that are disallowed as of December 31, 2013, these disallowed features will not be accepted.
3. If there are any validation requests where a lab has used a version of CAVS prior to CAVS 16.0 to create files and has not yet sent the appropriate files to the vendor, please regenerate everything using CAVS 16.0.

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

[11-13-13] -- New release of the CAVS algorithm validation testing tool to the CST Laboratories (CAVS15.2). The following additions, modifications and updates have been made to CAVS Version 15.1:

1. Corrected message displayed for RSA2 Key Generation verification.  It was erroneously displaying success on the screen when the summary and log files were indicating a failure.
2. Changes to format in RSADP files -Changed upper case K to lower case k in sample file
3. Corrections to RSA2 testing introduced when truncated SHAs were added.  Error was in using SHA1. 
4. Corrections to DRBG edit length dialog.
5. Removed response file creation in SP800-108.  This was here for generating example files for website.

The transition period ends February 13, 2014.

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-4 DSA, FIPS186-4 ECDSA, FIPS186-4 RSA, 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, the ECDSA2 Signature Generation Component and/or the RSADP component, the CST lab must use the CAVS 15.2 to validate the IUT.
2. For any algorithm validation request where a lab has used a version of CAVS prior to CAVS 15.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 February 13, 2014.
3. If there are any validation requests where a lab has used a version of CAVS prior to CAVS 15.2 to create files and has not yet sent the appropriate files to the vendor, please regenerate everything using CAVS 15.2.

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

[09-18-13] -- New release of the CAVS algorithm validation testing tool to the CST Laboratories (CAVS15.1). CAVS 15.1 contains all the additions and changes made to CAVS 15.0 plus some additional modifications and corrections. DO NOT USE CAVS VERSION 15.0. Instead, transition from CAVS Version 14.4 to CAVS Version 15.1. The following additions, modifications and updates have been made since CAVS Version 14.4:

1. - Added FIPS 180-4 SHA-512/224 and SHA-512/256 support to FIPS 186-4 DSA (i.e., DSA2), ECDSA (i.e., ECDSA2), and RSA (i.e., RSA2).
2. - Added SP800-56B RSADP component testing.
3. - Added prerequisite to ECDSA Signature Generation component. Requires prerequisite of DRBG or RNG because uses secret random number.
4. - For the NIST SP 800-135 IKEv1 and IKEv2 KDFs, the three fixed well-known group options (Groups 2, 4 and 14) are replaced by three drop-down lists of all valid shared secret lengths (groups), thus increasing the number of groups supported by testing.
5. - For the NIST SP 800-135 SSH KDF, testing with the TDES-CBC cipher is now optional instead of required. The user shall select all supported block ciphers out of the set of TDES CBC, AES-128 CBC, AES-192 CBC and AES-256 CBC.
6. - Fixed bug in NIST SP 800-135 SSH KDF tests. CAVS generated shared secret (i.e., K) values that were not valid because they had an unnecessary leading zero-valued byte.
7. - For NIST SP 800-38E XTS-AES, CAVS now allows testing with the tweak value input in both supported formats, the 128-bit hexadecimal string and the Data Unit Sequence number. Earlier versions of CAVS only tested for one format or the other.
8. - Fixed parsing bug in HMAC verify routine.
9. - AES Summary file corrected for AES Ctr mode information.
10. - Fixed bug in "Edit Input Lengths..." window for Hash_DRBG and HMAC_DRBG.
11. - Modifications to inf file (For internal use):
    1. GCM –make “Selected=” first line in GCM section (this will make it consistent with other sections)
    2. 135-Change name of “800135Selected” to “Selected”
    3. Have an empty line before the DES section – or remove the DES section.
    4. For each component, make it have its own section In the inf file for automation purposes (separate section for ECDSA SigGenComponent, RSASP1 component, RSADP component, etc.)
    5. Corrected label in SP800-135 log file
12. -Corrected truncated screen for SP800-135 IKEv2.

The transition period ends December 18, 2013.

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-4 DSA, FIPS186-4 ECDSA, FIPS186-4 RSA, 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, the ECDSA2 Signature Generation Component and/or the RSADP component, the CST lab must use the CAVS 15.1 to validate the IUT.
2. For any algorithm validation request where a lab has used CAVS Version 15.0 to create files, please regenerate everything using CAVS 15.1.
3. For any algorithm validation request where a lab has used a version of CAVS prior to CAVS 15.1 (excluding CAVS 15.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 December 18, 2013.
4. If there are any validation requests where a lab has used a version of CAVS prior to CAVS 15.1 (excluding CAVS 15.0) to create files and has not yet sent the appropriate files to the vendor, please regenerate everything using CAVS 15.1.

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

[09-17-13] -- New release of the CAVS algorithm validation testing tool to the CST Laboratories (CAVS15.0). The following additions, modifications and updates have been made to CAVS Version 15.0:

1. - Added FIPS 180-4 SHA-512/224 and SHA-512/256 support to FIPS 186-4 DSA (i.e., DSA2), ECDSA (i.e., ECDSA2), and RSA (i.e., RSA2).
2. - Added SP800-56B RSADP component testing.
3. - Added prerequisite to ECDSA Signature Generation component. Requires prerequisite of DRBG or RNG because uses secret random number.
4. - For the NIST SP 800-135 IKEv1 and IKEv2 KDFs, the three fixed well-known group options (Groups 2, 4 and 14) are replaced by three drop-down lists of all valid shared secret lengths (groups), thus increasing the number of groups supported by testing.
5. - For the NIST SP 800-135 SSH KDF, testing with the TDES-CBC cipher is now optional instead of required. The user shall select all supported block ciphers out of the set of TDES CBC, AES-128 CBC, AES-192 CBC and AES-256 CBC.
6. - Fixed bug in NIST SP 800-135 SSH KDF tests. CAVS generated shared secret (i.e., K) values that were not valid because they had an unnecessary leading zero-valued byte.
7. - For NIST SP 800-38E XTS-AES, CAVS now allows testing with the tweak value input in both supported formats, the 128-bit hexadecimal string and the Data Unit Sequence number. Earlier versions of CAVS only tested for one format or the other.
8. - Fixed parsing bug in HMAC verify routine.
9. - AES Summary file corrected for AES Ctr mode information.
10. - Fixed bug in "Edit Input Lengths..." window for Hash_DRBG and HMAC_DRBG.
11. - Modifications to inf file (For internal use):
    1. GCM –make “Selected=” first line in GCM section (this will make it consistent with other sections)
    2. 135-Change name of “800135Selected” to “Selected”
    3. Have an empty line before the DES section – or remove the DES section.
    4. For each component, make it have its own section In the inf file for automation purposes (separate section for ECDSA SigGenComponent, RSASP1 component, RSADP component, etc.)
    5. Remove dash, slash and spaces from truncated hash variable names (and other variables)

The transition period ends December 17, 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-4 DSA, FIPS186-4 ECDSA, FIPS186-4 RSA, 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, the ECDSA2 Signature Generation Component and/or the RSADP component, the CST lab must use the CAVS 15.0 to validate the IUT.
2. For any algorithm validation request where a lab has used a version of CAVS prior to CAVS 15.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 December 17, 2013.
3. If there are any validation requests where a lab has used a version of CAVS prior to CAVS 15.0 to create files and has not yet sent the appropriate files to the vendor, please regenerate everything using CAVS 15.0.

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

[09-05-13] - On July 19,2013, NIST announced the approval of Federal Information Processing Standard (FIPS) 186-4, the Digital Signature Standard.  All of the changes between FIPS 186-3 and FIPS186-4 had already been incorporated into the CAVP testing tool; the testing of FIPS186-3 implementations is identical to the testing of FIPS 186-4 implementations. There is no need for a transition period in which both FIPS 186-3 and FIPS 186-4 validation would be performed. Previous CAVP validations for FIPS 186-3 will be considered as equivalent to those for FIPS 186-4. Vendors should start using FIPS 186-4 immediately.

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

1. - For SP800-108 KDF in Counter Mode, added the ability to test implementations that put the counter in the middle of the input data. This is allowed by SP800-108.
2. - Minor correction in file used by tool - doesn't affect end users: In function WriteInfRSA2, changed reference to rsa2selected instead of rsaselected.

The transition period ends July 23, 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.4 to validate the IUT.
2. For any algorithm validation request where a lab has used a version of CAVS prior to CAVS 14.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 July 23, 2013.
3. If there are any validation requests where a lab has used a version of CAVS prior to CAVS 14.4 to create files and has not yet sent the appropriate files to the vendor, please regenerate everything using CAVS 14.4.

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

---

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

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: