1
$\begingroup$

I am working on securing a chat application, and I am not sure about which block cipher mode I should use. I am aware that I should avoid ECB as it's insecure, but what about CBC? I have watched several videos about block cipher modes, and I have read about it too, but I can't figure out what to use and why.

$\endgroup$
  • 4
    $\begingroup$ You should generally use an authenticated mode (e.g. GCM). What are you using this for? $\endgroup$ – forest Sep 27 '18 at 1:59
  • $\begingroup$ for securing a chat (IRC) I have always used CBC+HMAC or a more exotic mode like an OCB derivative $\endgroup$ – Richie Frame Sep 27 '18 at 2:29
  • $\begingroup$ I've removed the gcm tag as well. Tags are for questions, not prospective answers and there is certainly no need to include all cipher modes of operation here, authenticated or not. $\endgroup$ – Maarten Bodewes Sep 27 '18 at 15:19
7
$\begingroup$

ECB sucks big time. CBC sucks slightly less, but still a lot.

Generally speaking, when you begin to use an encryption system, it is to achieve a number of security-related properties, e.g. confidentiality and integrity of data. An "encryption mode" is a way to turn some elementary cryptographic function (e.g. AES) into something that can process messages of variable but potentially large size, in a way which achieves these properties. AES itself is called a "block cipher", which means that it really is a key-indexed family of permutations in a space of blocks of bits of a given size. In other words, AES does not encrypt message, no more than a brick provides housing. The encryption mode makes a system that encrypts messages in the same way as a mason assembles bricks to make a house.

Classical modes of operation extend a block cipher into a system that can encrypt a message and hopefully provide confidentiality. ECB does a bad job of it (see the penguin pictures in that Wikipedia page). CBC is better but still flawed (e.g. if the IV is predictable, chosen plaintext attacks can be used to leak information; also, it requires padding, whose processing can lead to padding oracles). Historically, CBC was much used because it seemed to be the best we had, but that was only when compared to ECB, which is atrocious in that respect.

Most importantly, classical modes provide encryption but not integrity. In almost every conceivable scenario that warrants use of encryption, integrity is also needed. There are algorithms called Message Authentication Codes that can provide integrity (but not encryption). Some MAC can even be built out of block ciphers, with yet again some "modes". It turned out that getting encryption and integrity at the same time is not easy to get right. A lot of protocols got it wrong (e.g. SSL/TLS, ant it created a lot of trouble). Thus cryptographers took up to the challenge, and decided to make new modes of operations that provide encryption and integrity, and do it properly. The general term for that is authenticated encryption (specifically, "AEAD" for authenticated encryption with additional data). The most well-known of these modes will be GCM, CCM and EAX. These modes are built over a block cipher that processes blocks of 16 bytes (128 bits), usually AES.

It is also possible to make AEAD systems out of other things than block ciphers. E.g. one can assemble (again, with great care) the stream cipher ChaCha20 with the MAC algorithm Poly1305, to get a very decent AEAD system (see RFC 7539).

A very frustrating feature of cryptography is that you cannot test for security. You can read documents and watch videos and make some code that runs, and add lots of unit tests that show you that your creation works and data flows in and out properly. None of these tests will tell you whether the result is secure. The best way to test security (and it's not a good way, it's just that all others are worse) is the combination of the following:

  1. You absorb all the known published science on the subject. For instance, for encryption, everything I wrote above should be known to you, and much more.

  2. You write your stuff while being extra careful, and documented precisely why all the attacks you know of (and there should be many, thanks to point #1) cannot work.

  3. You show your work to the world at large, and challenge all cryptographers to come test their skills against the might of your intellectual creation.

  4. While the said cryptographers close for the kill and feast on the corpse of your erstwhile proud system, and explain in graphic details all the amusing ways they found to metaphorically disembowel your security, you slump in a corner and sob pitifully.

  5. Then you get up, and start again at step #1, to do it properly this time.

  6. After a few iterations, if you work hard, you may finally achieve the creation of a system that actually survives the onslaught of your vindictive colleagues. Congratulations! The security of your encryption system is not proven yet (in fact, theoretically speaking, it is not clear that a secure encryption system can really exist at all), but at least you will have some reasonably good reasons to assert that if there still are weaknesses in your last creation, they are not obvious.

$\endgroup$
  • $\begingroup$ if you are looking for disk encryption , XEX , XTS (XEX with ciphertext stealing) and EME are good options $\endgroup$ – hardyrama Sep 27 '18 at 4:24
  • 1
    $\begingroup$ @hardyrama The question is definitely not about disk encryption and neither is this answer, making your comment rather off topic. Please also read my comment below the question. $\endgroup$ – Maarten Bodewes Sep 27 '18 at 15:25
  • $\begingroup$ I'd note that one should use a library that provides high-level APIs instead of primitives, eg NaCL, Libsodium, etc. That can remove a lot of the potential issues. $\endgroup$ – SAI Peregrinus Sep 28 '18 at 15:05

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.