34

I guess the gist of my question is: Are there cases in which CBC is better than GCM?

The reason I'm asking is that from reading this post by Matthew Green, and this question on cryptography stack exchange, and this explanation of an attack on XML (since I'm encrypting json in my work, although it's not streamed anywhere, but apparently a chosen cipertext attack is possible), then I should never, ever use CBC, and just use GCM.

In other words: There's no reason to use CBC, as long as GCM exists (which it does on OpenSSL, the library I use for my encryption work). Because:

GCM = CBC + Authentication.

Could someone please tell me whether my conclusions are correct?

IMPORTANT UPDATE: Since this question is getting popular so fast, I'd like to point out from my research that GCM IS NOT A SILVER BULLET. There's huge problem with GCM, which is that if you use the same IV twice it can compromise your key (due to the use of GMAC, so it's no fool-proof). In case you're paranoid (like myself), CBC with HMAC (encrypt then MAC) is probably the best if one wants to be on the safe side. (Also please correct me if I'm wrong on this update).

|improve this question
26

CBC and GCM are quite different. Both are secure when used correctly, but CBC isn't as parallelizable and lacks built-in authentication. Due to this, CBC is only really practical for encrypting local files that don't need random access.

As for any advantages it might have, CBC doesn't fail as catastrophically if the IV is reused, and it can be faster if implemented on basic hardware.

As for GCM, it's basically GCM = CTR + Authentication (not CBC). It's fast and secure if used correctly, and very versatile, hence its popularity.

|improve this answer
  • What do you mean with "random access" in this context? Do you mean decrypt a specific part of the file to read it? – The Quantum Physicist Apr 22 '18 at 15:56
  • Yes, randomly reading pirces of the file. CTR and GCM work better for this, as the whole beginning of the file doesn't have to be decrypted. – Therac Apr 22 '18 at 16:23
  • 8
    CBC does allow random access and parallelization for decryption. So in that respect it is no worse than GCM. You can also achieve limited parallelization for encryption with CBC by randomizing the block in the middle of your message and then compute blocks from that point forward and backwards in parallel on two threads. As for random access in GCM, you have to remember that you cannot authenticate a partial message, if you want authentication you have to authenticate the entire message. – kasperd Apr 22 '18 at 22:36
  • 2
    @kasperd and you definitely do want authentication. – Martin Bonner supports Monica Apr 23 '18 at 12:27
  • 1
    While it is true that you technically can exploit the parallelism of CTR inside GCM to get random access to a file, actually doing so is a mistake: you can't verify the authenticator without examining the entire ciphertext, so you'd be acting on unauthenticated data, which is pure evil—don't touch it! If you want random access to a large file, you should break it up into numbered chunks of bounded size (and authenticate the number), no matter what authenticated cipher you're using. – Squeamish Ossifrage Nov 10 '19 at 18:16
12
  1. CBC is older, which means more compatibility and just overall historical reasons.
  2. There are performance advantages, if you don't need GCM for authenticity. You often may want your own system for authenticity with some additional characteristics or you may not need it at all.
|improve this answer
  • Those benchmarks are for openssl which is not multithreaded. Since you cannot parallelize CBC encryption, a multithreaded implementation of GCM encryption (especially with PCLMUL) should be significantly faster. It pretty much gets the speed advantages of CTR if the CPU has PCLMUL. – forest Apr 24 '18 at 7:23
8

Big nitpick:

GCM = CBC + Authentication.

Nope, GCM = CTR + Authentication.

But in general you are right; CBC is an older mode that was invented back in the dark ages cryptographically speaking (no later than the 1970s), and is now disfavored because of the lack of built-in authentication and all the trouble that's been caused by padding oracles. One good practical example of this is that TLS 1.3 got rid of support for CBC.

GCM isn't a panacea either, however. It is strictly speaking correct, but has proven itself to be far from foolproof in practice:

  1. It fails spectacularly if you reuse a nonce. A single repeated nonce allows an adversary to recover its authentication subkey, plus to learn the XOR of the two messages with the same nonce.
  2. Its nonces are uncomfortably short (96 bits), which can be tricky to use with random nonces.

CBC doesn't have these problems. Random IVs work just fine (and are in fact required), and if you do repeat an IV you don't get catastrophic failure, you just leak information about equal plaintext prefixes.

|improve this answer
  • Thanks for the explanation. Is there something better than both in openssl? Also what if I change the IV to 32 bytes, since openssl allows that for gcm? – The Quantum Physicist Apr 23 '18 at 7:39
  • @TheQuantumPhysicist It is impossible to change the CBC IV to anything larger than the block size, which is 16 bytes. The IV itself actually acts as "dummy" plaintext to be encrypted first, otherwise the first block would behave like ECB. If you used Rijndael 256 (a 256-bit block variant of Rijndael, the cipher who's 128-bit block forms were standardized as AES), then you would need to use 32 byte IVs. – forest Apr 24 '18 at 7:25
  • @forest actually I meant gcm, not cbc in my question, because 96 bits is mentioned in the answer above as a weakness – The Quantum Physicist Apr 24 '18 at 13:56
7

Simply put - CBC came first. It is possible that you might have systems that only support CBC.

This would be the same question as "Why would I ever use RC4 and MD5 if AES and SHA-2 are available?" Compatibility and history. (Same with many other cipher choices.)

If all of your systems support AES-256-GCM, and have the resources to run it, and have a higher security need, then use AES=256-GCM.

For example, I have systems that do not support anything newer than SSL3, RC4 and MD5, with 1024-bit certs. (In 2018, yes). Sure, that's not much better than ROT13 these days, but it does enough for this data that doesn't actually require any encryption. (These days people call these things IoT.)

|improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.