- CSRC Home
- Projects / Research
- news & events
In Special Publication 800-38A, five confidentiality modes are specified for use with any approved block cipher, such as the AES algorithm. The modes in SP 800-38A are updated versions of the ECB, CBC, CFB, and OFB modes that are specified in FIPS Pub. 81; in addition, SP 800-38A specifies the CTR mode.
In the Addendum to SP 800-38A, NIST has specified three variants for extending the domain of the CBC mode using "ciphertext stealing."
The CMAC authentication mode is specified in Special Publication 800-38B for use with any approved block cipher. CMAC stands for cipher-based message authentication code (MAC), analogous to HMAC, the hash-based MAC algorithm.
CMAC is an essentially the One-Key CBC-MAC (OMAC) algorithm submitted by Iwata and Kurosawa. OMAC is an improvement of the XCBC algorithm, submitted by Rogaway and Black, which itself is an improvement of the CBC-MAC algorithm. XCBC efficiently addresses the security deficiencies of CBC-MAC; OMAC efficiently reduces the key size of XCBC.
Special Publication 800-38C specifies the CCM mode of the AES algorithm. CCM combines the counter mode for confidentiality with the cipher block chaining technique for authentication. The specification is intended to be compatible with the use of CCM within a draft amendment to the IEEE 802.11 standard for wireless local area networks.
Special Publication 800-38D specifies the Galois/Counter Mode (GCM) of the AES algorithm. GCM combines the counter mode for confidentiality with an authentication mechanism that is based on a universal hash function. GCM was designed to faciliate high-throughput hardware implementations; software optimizations are also possible, if certain lookup tables can be precomputed from the key and stored in memory.
The document includes discussion of two significant security issues that were raised in public comments: the unusual risks of using short tags (Ferguson), and the critical importance of the requirement for the uniqueness of the IVs (Joux).
Special Publication 800-38E approves the XTS-AES mode of the AES algorithm by reference to IEEE Std 1619-2007, subject to one additional requirement. The XTS-AES mode was designed to protect the confidentiality of data on block-oriented storage devices without providing authentication, in order to avoid expansion of the data; however, it does provide some protection against malicious manipulation of the encrypted data.
Special Publication 800-38F describes cryptographic methods that are approved for "key wrapping," i.e., the protection of the confidentiality and integrity of cryptographic keys. In addition to clarifying that some previously-approved methods are permitted for key wrapping, this publication specifies two deterministic authenticated-encryption modes of operation of the Advanced Encryption Standard (AES) algorithm: the AES Key Wrap (KW) mode and the AES Key Wrap With Padding (KWP) mode. An analogue of KW, called TKW, with the Triple Data Encryption Algorithm (TDEA) as the underlying block cipher, is also specified to support legacy applications.
Special Publication 800-38G specifies the FF1 and FF3 format-preserving encryption (FPE) modes of the AES algorithm. The acronym indicates that each mode is a Feistel-based method for FPE. Previously approved confidentiality modes are designed for binary data; FPE modes are designed for any kind of data, including non-binary formats, such as credit card numbers and social security numbers. Consequently, FPE facilitates the retrofitting of encryption technology to existing devices or software, where a conventional encryption mode might not be feasible.
FF1 was submitted to NIST by Bellare, Rogaway and Spies under the name FFX[Radix]; FF3 is the main component of the BPS mechanism that was submitted to NIST by Brier, Peyrin, and Stern.
Voltage Security, Inc. (which in the interim was acquired by HP, Inc.) provided NIST with a Letter of Assurance regarding the licensing of patents that may be relevant for the use of FPE modes.
NIST is actively considering the DFF proposal for format-preserving encryption, to supplement the FF1 and FF3 modes that are specified in Special Publication 800-38G. DFF was submitted by Joachim Vance and Mihir Belare; it is an extension of the VAES3 mode that NIST specified under the name FF2 in the public comment draft of that publication.