Integrity protection and error propagation None of the block cipher modes of operation above provide any integrity protection in their operation. This means that an attacker who does not know the key may still be able to modify the data stream in ways useful to them, without any surety those alterations will be detected. It is now generally well understood that wherever data is encrypted, it is nearly always essential to provide integrity protection, as the risks from not doing so are high. For such secure operation, the IV and ciphertext generated by these modes should be authenticated with a secure MAC, which must be checked by the receiver prior to decryption. Before the message integrity problem was widely recognized, it was common to discuss the "error propagation" properties of a mode of operation as a suitability criterion. It might be observed, for example, that a one-block error in the transmitted ciphertext would result in a one-block error in the reconstructed plaintext for ECB mode encryption, while in CBC mode such an error would affect two blocks: Some felt that such resilience was desirable in the face of random errors (eg, line noise), while others argued that it increased the scope for attackers to modify messages without assurance of detection if checked. However, when proper integrity protection is used, such an error will result (with high probability) in the entire message being rejected. If resistance to random error is desirable, error-correcting codes should be applied to the ciphertext before transmission. Some modes of operation have been designed to combine security and authentication. Examples of such modes are: XCBC, IACBC, IAPM, OCB, EAX, CWC, CCM, andGCM. These authenticated encryption modes are classified as single pass modes or double pass modes. Some modes also allow for the authentication of unencrypted associated data, and these are called AEAD (Authenticated-Encryption with Associated-Data) schemes. For example, EAX mode is a double pass AEAD scheme while OCB mode is single pass. Padding Main article: Padding (cryptography) Because a block cipher works on units of a fixed size, but messages come in a variety of lengths, some modes (mainly CBC) require that the final block be padded before encryption. Several padding schemes exist. The simplest is to add null bytes to the plaintext to bring its length up to a multiple of the block size, but care must be taken that the original length of the plaintext can be recovered; this is so, for example, if the plaintext is a C style string which contains no null bytes except at the end. Slightly more complex is the original DES method, which is to add a single one bit, followed by enough zero bits to fill out the block; if the message ends on a block boundary, a whole padding block will be added. Most sophisticated are CBC-specific schemes such as ciphertext stealing or residual block termination, which do not cause any extra ciphertext; these schemes are relatively complex. Schneier and Ferguson suggest two possibilities, both simple: append a byte with value 128 (hex 80), followed by as many zero bytes as needed to fill the last block, or pad the last block with n bytes all with value n. CFB, OFB and CTR modes do not require any special measures to handle messages whose lengths are not multiples of the block size, since they all work by XORing the plaintext with the output of the block cipher. The last partial block of plaintext is XORed with the first few bytes of the last keystream block, producing a final ciphertext block that is the same size as the final partial plaintext block. This characteristic of stream ciphers makes them suitable for applications that require the encrypted ciphertext data to be the same size as the original plaintext data, and for applications that transmit data in streaming form where it is inconvenient to add padding bytes. Other modes and other cryptographic primitives Many more modes of operation for block ciphers have been suggested. Some of them have been accepted, fully described (even standardised), and are in use. Others have been found insecure, and should never be used. NIST maintains a list of proposed modes for AES at  Disk encryption often uses special modes. Tweakable narrow-block encryption modes (LRW, XEX, and XTS) and wide-block encryption (CMC and EME) modes are designed to securely encrypt sectors of a disk. (See disk encryption theory) Block ciphers can also be used in other cryptographic protocols. They are generally used in modes of operation similar to the block modes described here. As with all protocols, to be cryptographically secure, care must be taken to build them correctly. There are several schemes which use a block cipher to build a cryptographic hash function. See one-way compression function for descriptions of several such methods. Cryptographically secure pseudorandom number generators (CSPRNGs) can also be built using block ciphers. Message authentication codes (MACs) are often built from block ciphers. CBC-MAC, OMAC and PMAC are examples. Authenticated encryption also uses block ciphers as components. It means to both encrypt and MAC at the same time. That is to both provide confidentiality andauthentication. IAPM, CCM, EAX, GCM and OCB are such authenticated encryption modes. GCM mode (Galois/Counter Mode) is a mode of operation for symmetric key cryptographic block ciphers. It is an authenticated encryption algorithm designed to provide both authentication and privacy. GCM mode is defined for block ciphers with a block size of 128 bits. GMAC is an authentication-only variant of the GCM. Contents [hide] 1 Encryption and authentication 2 Use 3 Performance 4 Tag size 5 Patents 6 See also 7 External links 8 Notes 9 References Encryption and authentication GCM encryption operation As the name suggests, GCM mode combines the well-known counter mode of encryption with the new Galois mode of authentication. The key feature is that the Galois field multiplication used for authentication can be easily computed in parallel thus permitting higher throughput than the authentication algorithms that use chaining modes, like CBC. The GF(2128) field used is defined by the polynomial The GHASH function is defined by where the inputs A and C, and the variables Xi for i = 0, ..., m + n + 1 are defined as GCM mode was designed by John Viega and David A. McGrew as an improvement to CarterWegman Counter CWC mode. On November 26, 2007 NIST announced the release of NIST Special Publication 80038D Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC making GCM and GMAC official standards. Use GCM mode is used in the IEEE 802.1AE (MACsec) Ethernet security, ANSI (INCITS) Fibre Channel Security Protocols (FC-SP), IEEE P1619.1 tape storage, and IETF IPsecstandards. Performance GCM requires one block cipher operation and one 128-bit multiplication in the Galois field per each block (128 bit) of encrypted and authenticated data. Tag size The bit-length of the tag, denoted t, is a security parameter. In general, t may be any one of the following five values: 128, 120, 112, 104, or 96. For certain applications, t may be 64 or 32, but the use of these two tag lengths constrains the length of the input data and the lifetime of the key. Appendix C in NIST SP 800-38D provides guidance for these constraints (for example, if t = 32 and the maximal packet size is 210 bytes, then the authentication decryption function should be invoked no more than 211 times; if t = 64 and the maximal packet size is 215 bytes, then the authentication decryption function should be invoked no more than 232 times). As with any tag-based authentication mechanism, if the adversary chooses a t-bit tag at random, it is expected to be correct for given data with probability 2 − t. With GCM, however, an adversary can choose tags that increase this probability, proportional to the total length of the ciphertext and additional authenticated data (AAD). Consequently, GCM is not well-suited for use with short tag lengths or very long messages. In particular, if n denotes the total number of blocks in the encoding (the input to the GHASH function), then there is a method of constructing a targeted ciphertext forgery that is expected to succeed with a probability of approximately n2 − t. Moreover, each successful forgery in this attack increases the probability that subsequent targeted forgeries will succeed, and leaks information about the hash subkey, H. Eventually, H may be compromised entirely and the authentication assurance is completely lost. Independent of this attack, an adversary may attempt to systematically guess many different tags for a given input to authenticated decryption, and thereby increase the probability that one (or more) of them, eventually, will be accepted as valid. For this reason, the system or protocol that implements GCM should monitor and, if necessary, limit the number of unsuccessful verification attempts for each key. Patents According to the authors' statement, GCM is unencumbered by patents. EAX mode From Wikipedia, the free encyclopedia EAX mode is a mode of operation for cryptographic block ciphers. It is an Authenticated Encryption with Associated Data (AEAD) algorithm designed to simultaneously protect both authentication and privacy of the message (Authenticated encryption) with a two-pass scheme, one pass for achieving privacy and one for authenticity for each block. EAX mode was submitted in October 3, 2003 to the attention of NIST in order to replace CCM as standard AEAD mode of operation, since CCM mode lacks some desirable attributes of EAX and is more complex. Contents [hide] 1 Encryption and authentication 2 Performance 3 Patent status 4 Use 5 See also 6 External links 7 References 8 Software implementations 9 Hardware implementations Encryption and authentication EAX is a flexible nonce-using two-pass AEAD scheme with no restrictions on block cipher primitive to be used, nor on block size, and supports arbitrary-length messages. Authentication tag length is arbitrarily sizeable up to the used cipher's block size. The block cipher primitive is used in CTR mode for encryption and as OMAC for authentication over each block through the EAX composition method, that may be seen as a particular case of a more general algorithm called EAX2 and described in "The EAX Mode of Operation" paper. The reference implementation in the aforementioned paper uses AES in CTR mode for encryption combined with AES OMAC for authentication. Performance Being a two-pass scheme, EAX mode is slower than a well designed one-pass scheme based on the same primitives. EAX mode has several desirable attributes, notably: provable security (dependent on the security of the underlying primitive cipher); message expansion is minimal, being limited to the overhead of the tag length; using CTR mode means the cipher need be implemented only for encryption, in simplifying implementation of some ciphers (especially desirable attribute for hardware implementation); the algorithm is "on-line", that means that can process a stream of data, using constant memory, without knowing total data length in advance; the algorithm can process static Associated Data (AD), useful for encryption/decryption of communication session parameters (where session parameters may represent the Associated Data). Notably, CCM mode lacks the last 2 attributes. Patent status The authors of EAX mode, Mihir Bellare, Phillip Rogaway, and David Wagner placed the work under public domain and have stated that they were unaware of any patents covering this technology. Thus, EAX mode of operation is believed to be free and unencumbered for any use. Use A modification of the EAX mode, so called EAX' , is used in the ANSI C12.22 standard for transport of meterbased data over a network. CCM mode From Wikipedia, the free encyclopedia CCM mode (Counter with CBC-MAC) is a mode of operation for cryptographic block ciphers. It is an authenticated encryption algorithm designed to provide bothauthentication and privacy. CCM mode is only defined for block ciphers with a block length of 128 bits. In RFC 3610, it is defined for use with AES. Contents [hide] 1 Encryption and authentication 2 Performance 3 Patents 4 See also 5 External links 6 References Encryption and authentication As the name suggests, CCM mode combines the well-known counter mode of encryption with the well-known CBC-MAC mode of authentication. The key insight is that the same encryption key can be used for both, provided that the counter values used in the encryption do not collide with the (pre-)initialization vector used in the authentication. A proof of security exists for this combination, based on the security of the underlying block cipher. In fact, the proof also applies to a generalization of CCM for any sizeblock cipher, and in fact, for any size cryptographically strong pseudo-random function (since in both counter mode and CBC-MAC, the block cipher is only ever used in one direction). CCM mode was designed by Russ Housley, Doug Whiting and Niels Ferguson. At the time CCM mode was developed, Russ Housley was employed by RSA Laboratories. A minor variation of the CCM, called CCM*, is used in the ZigBee standard. CCM* includes all of the features of CCM and additionally offers encryption-only and integrity-only capabilities. Performance CCM requires two block cipher encryption operations per each block of encrypted and authenticated message and one encryption per each block of associated authenticated data. Patents The catalyst for the development of CCM mode was the submission of OCB mode for inclusion in the IEEE 802.11i standard. Opposition was voiced to the inclusion of OCB mode because of a pending patent application on the algorithm. Inclusion of a patented algorithm meant significant licensing complications for implementors of the standard. While the inclusion of OCB mode was disputed based on these intellectual property issues, it was agreed that the simplification provided by an authenticated encryption system was desirable. Therefore Housley, et al. developed CCM mode as a potential alternative that was not encumbered by patents. Even though CCM mode is less efficient than OCB mode, a patent free solution was preferable to one complicated by patent licensing issues. Therefore, CCM mode went on to become a mandatory component of the IEEE 802.11i standard, and OCB mode was relegated to optional component status.