Podcast #128: We chat with Kent C Dodds about why he loves React and discuss what life was like in the dark days before Git. Listen now.

# Tag Info

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" ...

12

However, we are using the same nonce/IV to encrypt different data. No, don't do that if someone indeed gets hold of the plain-text nonce/IV and a number of different encrypted messages (which are encrypted using the same key) can they be able to decrypt the messages successfully? Actually, it doesn't matter if they know the nonce; if they get two ...

9

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 ...

9

This is not allowed. An AES-GCM implementation that accepts messages longer than $2^{39} - 256$ bits, i.e. $2^{32} - 2$ blocks, is broken. A protocol that is defined in terms of AES-GCM on messages longer than $2^{39} - 256$ bits is nonsensical. Protocols shouldn't be defined in terms of messages that long anyway because an adversary can waste the ...

8

Usually. However, if you are using 128-bit AES in CTR mode (remember that GCM is essentially just CTR with authentication), then a kind of attack called a multi-target attack can become possible. This attack is realistic when an attacker has a huge amount of stored ciphertext, each with a random key. While breaking a specific key requires performing up to ...

8

TL;DR: GCM provides excellent performance with the best security properties we expect from ciphers today (AEAD). GCM use CTR to build a stream cipher. This a well studied method, which has only one drawback: it absolutely needs some authentication to prevent bit flipping. Before GCM, CTR-then-MAC was the solution. One main advantage of stream ciphers is the ...

7

The diagram shows the gist of the algorithm, but not everything in it. The bulk of the encryption in GCM uses AES in CTR mode. "CTR mode" means that "successive" values of a counter are encrypted with the block function (the AES properly said) in order to yield a key-dependent pseudorandom stream which is combined (bitwise XOR) with the data to encrypt or ...

7

First of all, GCM is a form of counter mode. Which means that unlike with e.g. cipher block chaining, the output of one block depends on exactly one block of input. Worse, yet: You can modify a single bit and the decrypted result will differ in exactly that bit. Because if you are honest, a block cipher in counter mode is not a "block cipher" at all, but a (...

6

In your description, AES/GCM is always used with a new, fresh key, different from all previous keys. Thus, you are not reusing IV with the same key. In that sense, this should be fine from a security point of view. However, this seems overly complex and begs the question of: why? The simple way would be to use the static key "as is" and to use a random IV ...

6

You can have AES-GCM and streaming at the same time. But: Do not operate on unauthenticated data! Treat unauthenticated data like nuclear waste. The fact that the AES-CTR out of which AES-GCM is built technically can provide access to data before the authentication tag is verified is a red herring. Allowing access to the data before verifying the tag, ...

6

In AES-GCM, the IV should never be re-used. Re-using an IV may leak significant information about the authentication key (see this link form more info on how it works) . Without the authentication property, GCM mode become CTR mode, which is well known for it malleability, and therefore is not safe. However, the IV isn't secret, you can keep it in shared ...

6

Actually, it turns out that GHASH on 128 bit values is a permutation (unless $H=0$; this happens with probability $2^{-128})$ GHASH of a 128 bit value $X$ simplifies to $\text{GHASH}_H(X) = H \times X$, where $H$ is a function of the key (that is, will always be the same for a specific key), and $\times$ is multiplication in the field $GF(2^{128})$. This ...

6

updated per comments; Currently Netflix Uses AES-GCM I am now studying the AES encryption for real-time video stream. It seems that Netflix uses the AES-GCM (or CBC + MAC) mode for real-time video encryption and authentication. With MAC authentication, client can only get the MAC message after the> whole video is encrypted and authenticated. After ...

5

Yes. You can even use the nonce 0, and skip sharing state between the sender and receiver. While you're at it, consider using AES-256-GCM instead of AES-128-GCM to limit the danger of multi-target attacks. And stop there; don't waste your time with the painfully archaic OpenPGP or hopelessly dwimmy JOSE. If you really want to switch to an existing ...

5

I was wondering which of AES-GCM and AES-CBC would be best to use? If these two are your option, then it is essentially a no-brainer. Always use AES-GCM unless you really know what you are doing. Ideally I'd like to choose a solution that is "encrypt-then-mac", but I'm unsure which of those fit the bill here? That's what AES-GCM does internally. It ...

5

AES-GCM counter block is defined as nonce || IV || counter That is not true. AES-GCM effectively has two different versions. If you have a 96 bit nonce, then the counter block is (by your terminology) $$nonce || counter$$ However, if the nonce is any other size, it computes a temp value $J = GHASH(K, Nonce)$, and then makes the counter block J \...

5

If the authentication key $H$ is known to an attacker, he could authenticate forged ciphertext and make the receiver believe that it is authentic. This is very problematic, since the encryption part of the GCM mode is standard CTR mode encryption, which is actually a stream cipher. And like any other stream cipher, it is susceptible to a bit flip attack, ...

5

Using (plain) AES-GCM for streaming data (and, in particular, allowing the receiver to access the plaintext before it has been authenticated) breaks its security guarantee. Yes, it will "work", in the sense that the data will be correctly transmitted if an attacker doesn't tamper with it. But plain old AES-CTR will do that, too, so if that's all you care ...

5

Your colleague is wrong; assuming that the GCM nonces are generated correctly (that is, never repeats for the same key), there is no risk to GCM in repeating the VCC. GCM has the property that, as long as you never repeat the nonce for the same key, GCM guarantees both the privacy and integrity of the encrypted plaintext (assuming that AES is a strong block ...

5

Am I missing anything? No, you are not; if you use a key only once, that is, to encrypt a single message, and never use it to encrypt anything else, then it doesn't matter what nonce you use. An implicit 'all-00' nonce is as good as any. BTW: AES-GCM also uses the nonce as a part of the transform that generates the integrity tag; however, that addition ...

5

Latency, probably. $\mathrm{GHASH}_K(m) \oplus \mathrm{AES}_K(n)$ lets you compute both in parallel, whereas encrypting the $\mathrm{GHASH}$ output would add significant latency for short messages. The authors go to great detail about this in Section 3 of the original GCM document. A similar competing mode at the time, CWC, did indeed encrypt the MAC ...

4

Is it correct that Alice sends the ciphertext $CT=E_K(IV,AAD,D)$ to Bob together a timestamp $t$ like $CT||t$ That doesn't work; here, GCM doesn't protect $t$; the attacker can easily change it to anything he wants, and GCM will never notice. Now, you could expand the AAD to include the value $t$; , that is, we have $CT=E_K(IV,AAD || t,D)$. With that ...

4

From a cryptographic standpoint (ignoring implementation issues and password sniffing), the security depends primarily on the entropy $s$ in the password, and the number $n$ of iterations in PBKDF2. Work to break is about $n\,2^{s-1}$ SHA-256 (for large $n$). Per the obligatory XKCD, a good password has like 44 bits of entropy; a bad password (among the ...

4

First, usually AES-GCM is defined with just nonce and counter—if the term ‘IV’ appears, it is typically a stand-in for ‘nonce’; there's no separate nonce and IV parameters. So the input to the AES permutation is $n \mathbin\Vert c$, for a 96-bit nonce $n$ and 32-bit counter $c$. The question is whether we can safely use $n + c$ for a 128-bit nonce and 32-...

4

Knowing that it does not need to be secret and its only required property is to be unique, why not use a 128 bits true random number for the whole block? The counter instead of starting at 0 will start at some random value, wrapping around when reaching maximum value. First, imagine you're encrypting a sequence of messages with an ephemeral key scoped to ...

4

GCM is an authenticated wrapper around CTR mode. The authenticated data is only considered when verifing the authentication tag - after decrypting the data. If your adversary has the $(\text{iv}, \text{key}, \text{ciphertext})$ they can recover the $\text{message}$ but they cannot detect tampering. I recommend that you use Argon2i with a user's passphrase, ...

4

No. You're well above the birthday bound for a 128-bit block cipher. Using AES under a single key for more than about $2^{64}$ blocks of data is asking for trouble. The largest nonce you can use with standard AES-GCM is 96 bits,* which is safe sequentially, but you're probably not doing this sequentially unless you plan to wait a millennium for your ...

4

First things first: the passage you quote does not claim that GHASH is slower than AES. What it says is that if you replace AES/CTR with a much faster stream cipher, then the GHASH part will be comparatively expensive. There are many kinds of implementations, for both AES and GHASH; they have different performance characteristics, and they may be constant-...

4

Yes, it is secure to do this. Any cipher should be secure against known plaintext attacks after all. However, if you're using RSA then the RSA decryption routine will already throw an exception during the PKCS#1 v1.5 unpadding, so storing the 'lorem ipsum" data is not necessary: the padding already acts as the "lorem ipsum" data. If you still somehow ...

4

MixColumns implements a matrix multiplication, so InvMixColumns is the multiplication by the inverse of that matrix. Thus, it boils down to computing the inverse of the matrix. It can be tedious to do by hand, but it involves only straightforward computations. Alternatively, look up the AES standard itself (FIPS 197): the inverse matrix is spelled out ...

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