Announcements
[03-12-09] -- New release of the CAVS algorithm validation testing tool to the CMT Laboratories (CAVS7.1). In addition to minor modifications to enhance the tool, Version 7.1 of the CAVS tool adds testing for the draft of FIPS 186-3, Digital Signature Standard, Digital Signature Algorithm and file formating changes to the NIST SP 800-90 (DRBG) files to make them more similar to those used for other algorithms. As of the CAVS 7.1 release date, FIPS 186-3 is still in draft. No validations will be processed for this algorithm.
The transition period ends June 12, 2009.
As has been the policy in the past:
- EFFECTIVE IMMEDIATELY on any new validation requests for implementations of TDES, AES, DSA, SHA, RNG, RSA, HMAC, CCM, ECDSA, CMAC, DRBG 800-90, Key Agreement Scheme (KAS) FFC, KAS ECC and/or GCM 800-38D, the CMT lab must use the CAVS 7.1 to validate the IUT.
- For any algorithm validation request where a lab has used a previous version of CAVS to create files and has already sent the sample and request files to the vendor, NIST will accept validations using this tool up through June 12, 2009. The tool used to generate the files must be used to validate the files. For example, if CAVS7.0 was used to generate test vectors, then CAVS7.0 must be used to verify these values.
- If there are any validation requests where a lab has used a previous version of CAVS to create files and has not yet sent the appropriate files to the vendor, please regenerate everything using CAVS7.1.
The CAVP will also review special conditions on a case-by-case basis.
[12-24-2008] -- New release of the CAVS algorithm
validation testing tool to the CMT Laboratories (CAVS7.0). Version 7.0
of the CAVS tool adds testing for NIST SP 800-56A Recommendation for
Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography
and NIST SP 800-38D Recommendation for Block Cipher Modes of Operation:
Galois/Counter Mode (GCM) and GMAC.
In addition, file formating changes have
been made to the CCM Decrypt-Verification Process Test.
The transition period ends March 24, 2009.
As has been the policy in the past:
- For any algorithm validation request where a lab has used a previous
version of CAVS to create files and has already sent the sample and
request files to the vendor, NIST will accept validations using this
tool up through March 24, 2009. The tool used to generate the files
must be used to validate the files. For example, if CAVS6.1 was used
to generate test vectors, then CAVS6.1 must be used to verify these
values.
- If there are any validation requests where a lab has used a previous
version of CAVS to create files and has not yet sent the appropriate
files to the vendor, please regenerate everything using CAVS7.0.
Prior to the release of CAVS7.0, the CMVP allowed vendor affirmation
for SP800-56A implementations(IG1.12) and vendor affirmation for SP800-38D
implementations (IG.1.13). During the transition period, the vendor
has the option of either providing the vendor affirmation in FIPS140-2
IG1.12 or IG1.13 or going through the validation testing now available
in CAVS7.0. The transition period for accepting vendor affirmation for
SP800-56A is being determined but will exceed the 3 months specified
above. Please see the CMVP Announcements
for further information.
The CAVP will also review special conditions on a case-by-case basis.
[02-06-2008] -- New release of the CAVS algorithm
validation testing tool to the CMT Laboratories (CAVS6.1). The CAVS
6.1 tool fixes an error with HMAC_DRBG SP 800-90 DRBG testing. CAVS
6.0 was erroneously using the Hash_DRBG mechanism to generate returned
bits for the HMAC_DRBG tests in the .fax files. A second modification
made to CAVS6.1 regarding SP 800-90 DRBG testing involved changing the
requested number of bits to always be a multiple of the blocksize.
With regards to DSA validation testing, CAVS6.1
DSA screens have been modified to only allow modulus sizes providing
at least 80 bits of security as required by SP800-57; i.e., only the
1024 bit modulus size is allowable.
The transition period ends May 6, 2008.
As has been the policy in the past:
1. EFFECTIVE IMMEDIATELY on any new validation requests for implementations
of TDES, AES, DSA, SHA, RNG, DRBG, RSA, ECDSA, HMAC, CCM and/or CMAC,
the CMT lab must use the CAVS 6.1 to validate the IUT.
2. For any algorithm validation request where a lab has used a previous
version of CAVS to create files and has already sent the sample and
request files to the vendor, NIST will accept validations using this
tool up through May 6, 2008.
3. The exception to (2.) above is SP 800-90 DRBG testing for the HMAC_DRBG
mechanism using any SHA size. CAVS 6.1 must be used for all HMAC_DRBG
validation submissions.
4. If there are any validation requests where a lab has used a previous
version of CAVS to create files and has not yet sent the appropriate
files to the vendor, please regenerate everything using CAVS 6.1.
[11-15-2007] -- New release of the CAVS algorithm
validation testing tool to the CMT Laboratories (CAVS6.0). Verison 6.0
of the CAVS tool adds testing for NIST SP 800-90 Deterministic Random
Bit Generators.
The transition period ends February 15, 2008.
As has been the policy in the past:
- For any algorithm validation request where a lab has used a previous
version of CAVS to create files and has already sent the sample and
request files to the vendor, NIST will accept validations using this
tool up through February 15, 2008. The tool used to generate the files
must be used to validate the files. For example, if CAVS5.3 was used
to generate test vectors, then CAVS5.3 must be used to verify these
values.
- If there are any validation requests where a lab has used a previous
version of CAVS to create files and has not yet sent the appropriate
files to the vendor, please regenerate everything using CAVS6.0.
Prior to the release of CAVS6.0, the CMVP allowed vendor affirmation
for SP800-90 DRBG implementations. During the transition period, the
vendor has the option of either providing the vendor affirmation in
FIPS140-2 IG1.12 or going through the validation testing now available
in CAVS6.0. Please see the CMVP
Announcements for further information.
The CAVP will also review special conditions on a case-by-case basis.
[10-16-2006] [09-28-2006] New release of
the CAVS algorithm validation testing tool to the CMT Laboratories (CAVS5.2).
Version 5.2 of the CAVS tool includes the addition of tests to verify
the absence of an identified RSA X9.31 and PKCS#1 V1.5 algorithmic implementation
vulnerability. Information on this vulnerability can be found at the
Computer Security Resource Center (CSRC)
October 12, 2006 News. A statement discussing the attack is available.
CAVS5.2 also includes several modifications to the existing algorithm
validation tests to provide requested enhancements to the tool. Additional
information can be found at: Digital
Signature Standard (DSS)
The transition period ends December 31, 2006.
As has been the policy in the past:
- For any algorithm validation request where a lab has used a previous
version of CAVS to create files and has already sent the sample and
request files to the vendor, NIST will accept validations using this
tool up through December 31, 2006.
- If there are any validation requests where a lab has used a previous
version of CAVS to create files and has not yet sent the appropriate
files to the vendor, please regenerate everything using CAVS5.2.
- It is strongly advised that any CMVP cryptographic module in the
pre-validation phase re-test the RSA implementations with the new
version of CAVS.
- After December 31, 2006, all new received test reports to the CMVP
pre-validation queue must use the CAVS5.2 to validate RSA.
The CAVP will also review special conditions on a case-by-case basis.
For all validated cryptographic modules that incorporate RSA, the CMVP
and CAVP strongly suggest re-testing of the RSA algorithmic implementations
to determine if the vulnerability is present.
- If new CAVP testing is performed, and the vulnerability is determined
not to be present, the CMTL can send a letter to the CAVP along with
the ZIP'ed CAVS 5.2 files requesting a new algorithm certificate printed
to replace the already issued certificate referencing the new version
of CAVS. Note that the certificate number will not change. Only the
reference to the version of the CAVS tool will be changed.
- If CAVP testing is performed and the vulnerability is discovered,
the following revalidation process shall be followed:
- The algorithm implementation is changed to remove the vulnerability
resulting in a different version number,
- Submit the new test results to the CAVP for the new version
of the implementation. A new algorithm certificate will be issued
for the new version of the implementation. The certificate will
reference CAVS5.2.
- A revalidation letter can be submitted to the CMVP confirming
that the only change to the module is to the RSA algorithmic implementation
to correct the identified vulnerability; provide the reference
to the new RSA algorithmic validation certificate; and provide
a new version for the module. The CMVP will update the existing
FIPS 140-1 or FIPS 140-2 module certificate web site entry to
reference the new RSA algorithmic validation certificate and the
new module version number associated with that certificate. No
new FIPS 140-2 validation certificate will be issued. An updated
Security Policy is required to include the new information. Any
other changes to the validated cryptographic module shall handled
in accordance with IG G.8 - Revalidation Requirements.
Please direct any CAVP or CMVP questions to the appropriate contact.
[04-03-2006] New release of the CAVS algorithm
validation testing tool to the CMT Laboratories (CAVS5.0).Version 5.0
of the CAVS tool includes the addition of a validation test suite for
the CMAC algorithm. Documentation describing the CMAC validation tests
is located in the CMACVS document accessible via our webpage. CAVS5.0
also includes several modifications to the existing algorithm validation
tests to provide requested enhancements to the tool.
The transition period ends July 3, 2006.
As has been the policy in the past:
- EFFECTIVE IMMEDIATELY on any new validation requests for implementations
of TDES, AES, DSA, SHA, RNG, RSA, ECDSA, HMAC, CCM and/or CMAC, the
CMT lab must use the CAVS5.0 to validate the IUT.
- For any algorithm validation request where a lab has used a previous
version of CAVS to create files and has already sent the sample and
request files to the vendor, NIST will accept validations using this
tool up through July 3, 2006.
- If there are any validation requests where a lab has used a previous
version of CAVS to create files and has not yet sent the appropriate
files to the vendor, please regenerate everything using CAVS5.0.
The CAVP will also review special conditions on a case-by-case basis.
[05-11-2005] New release of the CAVS algorithm
validation testing tool to the CMT Laboratories (CAVS4.6). Version 4.6
of the CAVS tool includes a couple of minor modifications. These modifications
include:
The transition period ends July 3, 2006.
As has been the policy in the past:
- For HMAC: Enforcing the minimum length allowed for the key size.
As specified by FIPS PUB 198 The Keyed-Hash Message Authentication
Code (HMAC) Section 3 Cryptographic Keys, it states: "The size
of the key, K, shall be equal to or greater than L/2, where L is the
size of the hash function output." The minimum key size is dependent
on the hash function supported by the HMAC implementation and is specified
on each screen for HMAC.
- For DES and Triple-DES: The message displayed after validating results
has been modified to indicate whether or not the tests have passed
successfully.
The transition period ends August 11, 2005.
As has been the policy in the past:
- EFFECTIVE IMMEDIATELY on any new validation requests for implementations
of DES, Triple-DES, AES, DSA, SHS, RNG, RSA, ECDSA, HMAC and/or CCM,
the CMT lab must use the CAVS4.6 to validate the IUT.
- For any algorithm validation request where a lab has used CAVS4.5
to create files and has already sent the sample and request files
to the vendor, NIST will accept validations using this tool during
the transition period which expires August 11, 2005. The CMT Laboratory
should contact those vendors to inform them that the algorithm validation
files supplied to them will expire at the end of the transition period.
If the vendor has not returned the response files by that time, the
request and sample files will have to be regenerated by the CAVS4.6
tool and the vendor will have to regenerate the response files.
- If there are any validation requests where a lab has used a previous
version of CAVS to create files and has not sent the appropriate files
to the vendor yet, please regenerate everything using CAVS4.6.
The CAVP will also review special conditions on a case-by-case basis.
[01-31-2005] New release of the CAVS algorithm
validation testing tool to the CMT Laboratories
- New RNG algorithm testing
- Algorithm testing available for NIST-Recommended Random Number
Generator Based on ANSI X9.31 Appendix A.2.4 Using the 3-Key Triple
DES and AES Algorithms.
- During the transition period, ANSI X9.31 RNG implementations
using 3-Key Triple-DES and AES algorithms will continue to be
recognized as FIPS Approved "vendor affirmed" or referenced
to the new algorithm certificate if available for FIPS 140-2 validations.
After the transition period, these RNG implementations will only
be recognized on new FIPS 140-2 validations as FIPS Approved when
referenced to an algorithm certificate.
- All references to RNG on FIPS 140-2 validation certificates
that have RNG certificates will be referenced as RNG (Cert. nnn).
The transition period ends April 30, 2005. New FIPS 140-2 validation
test reports received from CMT Laboratories after the transition period
must conform to the new algorithm testing schemes indicated above. For
FIPS 140-2 re-validations received after April 30, 2005, if the security
relevant changes do not require new algorithm testing, new algorithm
testing is not required. If an algorithm is changed or added, that algorithm
must conform to the new algorithm testing schemes indicated above.
For algorithm validation requests where a CMT Laboratory has used CAVS4.3
to create files and has already sent the sample and request files to
the vendor, NIST will accept validations using the old tools during
the transition period. The CMT Laboratory should contact those vendors
to inform them that the algorithm validation files supplied to them
will expire at the end of the transition period. If the vendor has not
returned the response files by that time, the request and sample files
will have to be regenerated by the CAVS4.4 tool and the vendor will
have to regenerate the response files. The CMVP will also review special
conditions on a case-by-case basis.
[09-01-2004] New release of the CAVS algorithm
validation testing tool to the CMT Laboratories (CAVS4.0)
- New ECDSA algorithm testing
- Testing is now available for conformance to the ECDSA algorithm.
- During the transition period, ECDSA algorithms will continue
to be recognized as FIPS Approved "vendor affirmed"
or referenced to the new algorithm certificate if available for
FIPS 140-2 validations. After the transition period, ECDSA will
only be recognized on new FIPS 140-2 validations as FIPS Approved
when referenced to an algorithm certificate.
- All references to ECDSA on FIPS 140-2 validation certificates
that have ECDSA certificates will be referenced as ECDSA (Cert.
nnn).
- New HMAC algorithm testing
- Testing is now available for conformance to the HMAC algorithm.
- During the transition period, the HMAC algorithm will continue
to be recognized as FIPS Approved "vendor affirmed"
or referenced to the new algorithm certificate if available for
FIPS 140-2 validations. After the transition period, HMAC will
only be recognized on new FIPS 140-2 validations as FIPS Approved
when referenced to an algorithm certificate.
- All references to HMAC on FIPS 140-2 validation certificates
that have HMAC certificates will be referenced as HMAC (Cert.
nnn).
- New CCM algorithm testing
- Testing is now available for conformance to the CCM algorithm.
- CCM will only be recognized on new FIPS 140-2 validations as
FIPS Approved when referenced to an algorithm certificate.
- All references to CCM on FIPS 140-2 validation certificates
will have CCM certificates and will be referenced as CCM (Cert.
nnn).
The transition period ends December 1, 2004. New FIPS
140-2 validations or re-validation test reports (RE: FIPS 140-2 IG G.8)
received from CMT Laboratories after the transition period must conform
to the new algorithm testing schemes indicated above and meet ALL current
standards and IGs.
For algorithm validation requests where a CMT Laboratory has used CAVS3.3
to create files and has already sent the sample and request files to
the vendor, NIST will accept validations using the old tools during
the transition period. The CMT Laboratory should contact those vendors
to inform them that the algorithm validation files supplied to them
will expire at the end of the transition period. If the vendor has not
returned the response files by that time, the request and sample files
will have to be regenerated by the CAVS4.0 tool and the vendor will
have to regenerate the response files. The CMVP will also review special
conditions on a case-by-case basis.
[06-14-2004] New release of the CAVS algorithm
validation testing tool to the CMT Laboratories (CAVS 3.3)
- Added Key Generation to RSA X9.31.
- Added validation tests for the General Purpose RNG specified in
FIPS 186-2 Change Notice.
- Added the ability to select more than one SHA when running validation
tests for RSA. This has changed the format of the Signature Generation
and Signature Verification files.
[03-11-2004] New release of the CAVS algorithm
validation testing tool to the CMT Laboratories
New and Updated Implementation Guidance:
- New rDSA algorithm testing
- Testing is now available for conformance to several versions
of the rDSA algorithm.
- During the transition period, rDSA algorithms will continue
to be recognized as FIPS Approved "vendor affirmed"
or referenced to the new algorithm certificate if available for
FIPS 140-2 validations. After the transition period, rDSA will
only be recognized on new FIPS 140-2 validations as FIPS Approved
when referenced to an algorithm certificate.
- All references to RSA on FIPS 140-2 validation certificates
that have rDSA certificates will be referenced as rDSA (Cert.
nnn).
- Expanded SHS algorithm testing
- Testing is now available for conformance to SHA-1, SHA-256,
SHA-384, and SHA-512 algorithms.
- SHS algorithms will only be recognized as FIPS Approved with
reference to an algorithm certificate.
- All references to Secure Hash Algorithms on FIPS 140-2 validation
certificates that have SHS certificates will be referenced as
SHS (Cert. nnn).
- New RNG algorithm testing
- Testing is now available for conformance to the RNG algorithms
that are referenced in FIPS 140-2 Annex C.
- During the transition period, FIPS Approved RNG's found in FIPS
140-2 Annex C that do not have an algorithm certificate can still
be used in FIPS Approved mode and will not be listed on the FIPS
140-2 validation certificate. They will only be listed on the
FIPS 140-2 validation certificate if an algorithm certificate
is available. After the transition period, FIPS Approved algorithms
that can be tested can only be used in a FIPS Approved mode with
reference to an algorithm certificate. Where testing is not available
for the FIPS Approved algorithms, they will be annotated as "vendor
affirmed".
- All references to RNG algorithms on FIPS 140-2 validation certificates
will be referenced as RNG (Cert. nnn).
The transition period ends June 04, 2004. New FIPS
140-2 validations or re-validation test reports (RE: FIPS 140-2 IG G.8)
received from CMT Laboratories after the transition period must conform
to the new algorithm testing schemes indicated above and meet ALL current
standards and IGs.
For algorithm validation requests where a CMT Laboratory has used CAVS1.3
or DSSVS to create files and has already sent the sample and request
files to the vendor, NIST will accept validations using the old tools
during the transition period. The CMT Laboratory should contact those
vendors to inform them that the algorithm validation files supplied
to them will expire at the end of the transition period. If the vendor
has not returned the response files by that time, the request and sample
files will have to be regenerated by the CAVS3.0 tool and the vendor
will have to regenerate the response files. The CMVP will also review
special conditions on a case-by-case basis.