Editing Advanced Encryption Standard (section)

== NIST/CSEC validation ==
The [[CMVP|Cryptographic Module Validation Program]] (CMVP) is operated jointly by the United States Government's [[National Institute of Standards and Technology]] (NIST) Computer Security Division and the [[Communications Security Establishment]] (CSE) of the Government of Canada. The use of cryptographic modules validated to NIST [[FIPS 140-2]] is required by the United States Government for encryption of all data that has a classification of [[Sensitive but Unclassified]] (SBU) or above. From NSTISSP #11, National Policy Governing the Acquisition of Information Assurance: "Encryption products for protecting classified information will be certified by NSA, and encryption products intended for protecting sensitive information will be certified in accordance with NIST FIPS 140-2."<ref name="cnss.gov">{{cite web |url=http://www.cnss.gov/Assets/pdf/nstissp_11_fs.pdf |title=NSTISSP No. 11, Revised Fact Sheet, National Information Assurance Acquisition Policy |access-date=2012-05-29 |url-status=dead |archive-url=https://web.archive.org/web/20120421103818/http://www.cnss.gov/Assets/pdf/nstissp_11_fs.pdf |archive-date=2012-04-21}}</ref>

The Government of Canada also recommends the use of [[FIPS 140]] validated cryptographic modules in unclassified applications of its departments.

Although NIST publication 197 ("FIPS 197") is the unique document that covers the AES algorithm, vendors typically approach the CMVP under FIPS 140 and ask to have several algorithms (such as [[Triple DES|Triple&nbsp;DES]] or [[SHA1]]) validated at the same time. Therefore, it is rare to find cryptographic modules that are uniquely FIPS 197 validated and NIST itself does not generally take the time to list FIPS 197 validated modules separately on its public web site. Instead, FIPS 197 validation is typically just listed as an "FIPS approved: AES" notation (with a specific FIPS 197 certificate number) in the current list of FIPS 140 validated cryptographic modules.

The Cryptographic Algorithm Validation Program (CAVP)<ref>{{cite web |url=http://csrc.nist.gov/groups/STM/cavp/index.html |title=NIST.gov – Computer Security Division – Computer Security Resource Center |publisher=Csrc.nist.gov |access-date=2012-12-23 |url-status=live |archive-url=https://web.archive.org/web/20130102044410/http://csrc.nist.gov/groups/STM/cavp/index.html |archive-date=2013-01-02}}</ref> allows for independent validation of the correct implementation of the AES algorithm. Successful validation results in being listed on the NIST validations page.<ref>{{cite web |url=http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140val-all.htm |title=Validated FIPS 140-1 and FIPS 140-2 Cryptographic Modules |url-status=dead |archive-url=https://web.archive.org/web/20141226152243/http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140val-all.htm |archive-date=2014-12-26 |access-date=2014-06-26}}</ref> This testing is a pre-requisite for the FIPS 140-2 module validation. However, successful CAVP validation in no way implies that the cryptographic module implementing the algorithm is secure. A cryptographic module lacking FIPS 140-2 validation or specific approval by the NSA is not deemed secure by the US Government and cannot be used to protect government data.<ref name="cnss.gov"/>

FIPS 140-2 validation is challenging to achieve both technically and fiscally.<ref name="openssl">{{cite web |author=OpenSSL, openssl@openssl.org |url=http://openssl.org/docs/fips/fipsnotes.html |title=OpenSSL's Notes about FIPS certification |publisher=Openssl.org |access-date=2012-12-23 |url-status=dead |archive-url=https://web.archive.org/web/20130102203126/http://www.openssl.org/docs/fips/fipsnotes.html |archive-date=2013-01-02}}</ref> There is a standardized battery of tests as well as an element of source code review that must be passed over a period of a few weeks. The cost to perform these tests through an approved laboratory can be significant (e.g., well over $30,000 US)<ref name="openssl" /> and does not include the time it takes to write, test, document and prepare a module for validation. After validation, modules must be re-submitted and re-evaluated if they are changed in any way. This can vary from simple paperwork updates if the security functionality did not change to a more substantial set of re-testing if the security functionality was impacted by the change.