# Tag Info

88

GCM and CBC modes internally work quite differently; they both involve a block cipher and an exclusive-or, but they use them in different ways. In CBC mode, you encrypt a block of data by taking the current plaintext block and exclusive-oring that wth the previous ciphertext block (or IV), and then sending the result of that through the block cipher; the ...

45

Before answering your questions: GCM is an authenticated encryption mode of operation, it is composed of two separate functions: one for encryption (AES-CTR) and one for authentication (GMAC). It receives as input: a Key a unique IV Data to be processed only with authentication (associated data) Data to be processed by encryption and authentication It ...

37

CCM (Counter with CBC-MAC) Message authentication (via CBC-MAC) is done on the plaintext not the ciphertext. (This is generally not a desireable feature.) On the encrypt operation, the encryption and MAC could happen in parallel, but generally do not (typically because there is just one AES engine in a chip, just one AES thread at a time, etc.). Similar ...

36

I'll answer in order: Output size = input size That's correct, GCM uses CTR internally. It encrypts a counter value for each block, but it only uses as many bits as required from the last block. CTR turns the block cipher into a stream cipher. Note that this doesn't include the optional additional authenticated data (AAD), the optional IV nor the required ...

35

AES-GCM has the following problems: In the case of nonce reuse both integrity and confidentiality properties are violated. If the same nonce is used twice, an adversary can create forged ciphertexts easily. When short tags are used, it is rather easy to produce message forgeries. For instance, if the tag is 32 bits, then after $2^{16}$ forgery attempts and $... 31 In comparison to CBC mode and HMAC, GCM mode is quite a commonly better alternative. But, I'll go to detail where it necessarily is not. Just like Richie Frame, I also do not agree that CBC + HMAC is always the best comparison target. I've added a few other details. Hope you find them useful. Against CBC and HMAC I'll discuss downsides first. The ... 22 Contrary to what Stephen says, you absolutely can compute the tag in parallel. Here's how it works; the tag computation is essentially "assemble the AAD, data, the length field and$Encr(Nonce)$into a series of values$x_n, x_{n-1}, x_{n-2}, ..., x_0$", and then "compute the polynomial$x_nh^n + x_{n-1}h^{n-1} + x_{n-2}h^{n-2} + ... + x_0h^0$This ... 19 In general the AAD itself is not required or won't change the security of the GCM mode of operation itself. It may however directly influence the security of the protocol in which GCM is deployed. For instance, you may have specific configurable parameters outside the ciphertext itself. These parameters may very well include: version number of the ... 19 There are three important points here to consider. 1. We work in$\mathbb{F}_2[X]$. This means that we do additions and multiplications of binary polynomials, i.e. polynomials whose coefficients are 0 or 1. The addition of two polynomials is then a bitwise XOR; there is no carry propagation. Similarly, the multiplication is called a "carry-less" ... 18 From the proposal of GCM (rewritten if statement): if$\operatorname{len}(IV) = 96$then$Y_0 = IV || 0^{31}1$else$Y_0 = \operatorname{GHASH}(H, \{\}, IV)$. So there are additional calculations for IV's other than 96 bits. This is why the original proposal has this recommendation: 96-bit IV values can be processed more efficiently, so that [ed: ... 16 The "hard part" about GCM implementation is resistance to side-channel attacks, especially cached-based. GCM is the combination of AES-CTR, and a custom MAC that relies on multiplications in a binary field (GF(2128)). Efficient implementation of that operation classically uses tables, which can lead to cache-timing attacks because the accessed table slots ... 16 For the GCM mode polynomial, it's likely that they simply looked it up in a table. Low-weight irreducible polynomials over${\rm GF}(2)$are useful enough that people have spent time compiling lists of them; the one I linked to above (Seroussi 1998) is fairly often cited, and indeed contains the GCM polynomial. Of course, this just changes the question to ... 13 Yes, the nonce will be used with a counter appended in order to generate the CTR mode keystream. It will also be used as an input to GHASH: which is a polynomial MAC used to authenticate the data. The nonce itself does not have to be random, it can be a counter. But it absolutely must be unique for each message encrypted with the same key. Using GCM on two ... 13 AES has a block-size of 128 bits in all its variants. The number in AES-128/192/256 is the key-size. Rijndael, the block-cipher that became AES, also supports 256 bit blocks, but that part was not standardized as AES. Since the block-size is 128 bits, GCM works exactly the same way for AES-256 as it does for AES-128. 13 GCM does not provide secure hashing. In general, a MAC has all the properties of a hash only against an adversary who does not know the key. If you want to use the function as a MAC then the key has to be public and then A MAC is not a secure hash. With most common MAC constructions other than HMAC, if you know the key, you can easily construct, at least, a ... 12 AEAD modes like GCM are authenticated encryption with associated data; this setting only affects the associated data half of that. The ciphertext itself is still authenticated. The associated data portion is there to provide contextual information for the authentication of the ciphertext. Usually this data is something that's outside of direct control of the ... 12 The authentication tag is defined as an output parameter in GCM (see section 7, step 7 of NIST SP 800-38D). In all the API's I've encountered it's appended to the ciphertext. Where it is actually placed is up to the protocol designer. The protocol designer may well consider the place behind the ciphertext as ad hoc default though. The name "tag" of course ... 12 AAD has nothing to do with making it "more secure". The aim of AAD is to attach information to the ciphertext that is not encrypted, but is bound to the ciphertext in the sense that it cannot be changed or separated. (Conceptually, the MAC is computed over the AAD and the ciphertext together.) 11 The GCM authentication tag doesn't need to be encrypted. Just attach it to the ciphertext in the clear. A very quick intuitive justification: It's an authentication tag derived from the ciphertext, it doesn't contain any sensitive information itself. The security of the GCM model assumes the tag is left in the open. (The GCM spec, SP 800-38D, shows the ... 11 From RFC 5246, section 6.2.3.3: AEAD Ciphers: AEAD ciphers take as input a single key, a nonce, a plaintext, and "additional data" to be included in the authentication check, as described in Section 2.1 of [AEAD]. The key is either the client_write_key or the server_write_key. No MAC key is used. However in RFC 5246, section 5: HMAC and ... 10 eBACS, as given by CodesInChaos, is a great resource, and it provides much more data than I could hope to give in this answer. However, the page is not explicit about whether or not AES-NI was used — looking at the results, it doesn't seem so. For an extremely shallow analysis, but allowing us to know for-sure about hardware acceleration, we can use ... 10 The answer is, yes, you can get FIPS certification even if you don't implement every approved cryptographical primitive, or if you don't implement every possible option of those primitives. When you undergo FIPS testing, they ask you to fill out an "information form" that asks for the details of what cryptography you claim to implement. These includes ... 10 AES-GCM uses single block cipher operation and can be processed in parallel, therefore it should be faster. CTR+HMAC requires block cipher and hash function, which usually can't be processed in parallel. Also it requires 2 keys. It is often miss-implemented (MAC-than-encrypt or MAC-and-encrypt, using single key). Cipher-text length is the same for same ... 10 Actually section 6.2.3.3 of RFC 5246 talks about the associated data: The additional authenticated data, which we denote as additional_data, is defined as follows: additional_data = seq_num + TLSCompressed.type + TLSCompressed.version + TLSCompressed.length; where "+" denotes concatenation. So the sequence number, the packet ... 10 My question is... why? There are a number of different algorithms that perform$GF(2^{128})$multiplication, all with different trade-offs (speed on specific platforms, program size, memory usage, complexity, side channel resistance, etc). NIST doesn't care which one you use, as long as you get the expected result at the end. As for why NIST decided to ... 9 If you go through the math, it appears that exactly the expected amount of ciphertext expansion is happening. Here's what's happening: The GCM takes the plaintext as a byte string of size N, and generates a ciphertext which is a byte string of size N+28, where 12 of the 28 is the nonce, and the other 16 is the authentication tag. Then, that octet string ... 9 Reusing an IV once opens you up to someone finding the XOR of those two plaintext, seriously compromising their confidentiality. Moreover, with GCM, a single IV reuse leaks significant information about the key used for authentication; if there are even a few pairs of reused IVs (not even one IV used many times; a few IVs each of which are used twice is ... 9 The source of the limitation lies in the fact that GCM has a fixed block counter using a 32-bit integer. Since the block size is$2^7$bits, the total amount that can be encrypted with the CTR component is$2^{39}$bits. The first limit reducing this by 128-bits is the fact that the block counter starts at 1 and not 0, at least with a 96-bit nonce. Nonce ... 9 This is terrible. In GCM, if you use the same nonce, then the authenticator is completely broken (for all messages in the future). You should never assume that the attacker doesn't know the filename either. You MUST use different IVs. 9 This additional 32 bit nonce acts as a salt, and makes multicollision attacks$2^{32}\$ times harder. In this attack, the attacker collects a huge number of TLS sessions, each with a record encrypted with the same nonce. He then selects a random key, and generates the counter mode keystream for the key (and the fixed nonce); he then checks if that key ...

Only top voted, non community-wiki answers of a minimum length are eligible