Hot answers tagged

46

Short: CBC mode in context of TLS protocol has had security issues, and would have had to be reworked. AES-CBC mode combined with decent HMAC can be as secure as AES-GCM. However, combining the cipher and MAC securely has been in practice found to be much easier said than done. Also, padding that is required by AES-CBC mode complicates things. In ...


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


17

TLS 1.3 is a reboot of the TLS protocol which focused on up to date cryptography rather than backwards compatibility. Now CBC is not as secure as you make it to be, and the way that it was used in TLS made it particularly vulnerable. To note: in TLS the HMAC authentication tag was created over the plaintext rather than the ciphertext. This made TLS ...


15

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


10

from what I know CBC is the most secure Mode of operation for the AES block cipher I'm not exactly sure why you say this; however, there has been a couple of practical problems with CBC mode in the past: Padding Oracle attacks; as originally designed in SSL (and carried into TLS 1.2), the way TLS implements CBC mode (with the padding and the HMAC) is prone ...


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


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

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


7

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


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

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


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


6

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


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

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

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

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


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

LibreSSL supports AEAD ciphers, including aes-256-gcm: $ openssl enc -aes-256-gcm -nosalt -p -in file.in -out file.out enter aes-256-gcm encryption password: Verifying - enter aes-256-gcm encryption password: key=A744E1091C25BABD36B50E40FB8D311A672722729CEA6E217AD9FA8AF23CAF57 iv =BDEEA37B93BB989C6C40665B If you don't mind writing your own software, there ...


5

Well, supposing everything is properly domain separated, nonces are always generated randomly for encryption queries, and your KDF behaves like a perfectly random function, the first step is to bound the probability of a nonce repeat. A birthday bound tells us that this happens with probability at most $$ q^2/2^{256}\,, $$ where $q$ is the number of ...


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

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


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