A Bluffers Guide To Symmetric Key Encryption Modes

A Bluffers Guide To Symmetric Key Encryption Modes

Symmetric key encryption involves a single key to encrypt and decrypt and where Bob and Alice can use the same encryption key. The two most popular symmetric key methods are AES — Advanced Encryption Standard — and ChaCha20. Along with this, we either have a block cipher or a stream cipher. With a block cipher, we process a number of bytes at a time with our ciphering process. With AES, we have a 128-bit block size, and thus process 16 bytes for each block. For a stream cipher, we generate a pseudo infinitely long key stream from a passphrase or random value, and then just XOR this with the plaintext. The size of the key stream is match to the number of bytes in the plaintext. To decrypt, we just generate the same key stream, and XOR it with the ciphertext to recover the plaintext.

I am often surprised by how little care many companies have in their encryption process and do not review the fundamental weaknesses of using symmetric key encryption. For many, it is a tick-box approach, where an auditor just asks if they are using encryption or not. It should not be, and there are many weaknesses that need to be taken into account. So, here’s the bluffer’s guide to modes in AES:

• ECB (Electronic Code Book). This is the fastest mode and should NEVER be used, as there is no salt (IV) used in the ciphering process. This mode is only used for academic purposes to show what can go wrong if salt is not added to the encryption process. With this, the ciphertext will always be the same for the same plaintext, and it is possible to easily crack by looking at patterns in the data.

All of the other modes have a salt (IV or nonce) value:

• CTR (Counter). This is an excellent mode which has a counter for each block, and then converts to a stream cipher. It is nearly as fast as ECB, and can be processed in parallel. It can be played back in a different session and can have little in the way to integrity check, and where Eve can flip bits and change the plaintext from the ciphertext. We need all the ciphertext before we can use the plaintext. A demo of breaking CTR is: https://billatnapier.medium.com/can-i-break-aes-encryption-yes-31bdf539aba0
• GCM (Galois/Counter Mode). This is almost the same as CTR and is a stream cipher, but slower than CTR (but still relatively fast overall. It has the advantage of adding additional data, such as for a session ID, and thus protects against playback. GCM (Galois/Counter Mode). The main change from CTR is to add a MAC, and so the bit-flipping method would be near impossible to implement. This mode implements AEAD (Authenticated Encryption with Additional Data), and is useful in defending against playback attacks. It can suffer from nonce reuse, though.
• CBC (Cipher Block Chain). This is a block mode which thus requires padding before encryption and after decryption. While achieving the same speeds as ECB for a small amount of data, it slows down with larger amounts — because of the block-chaining process. It is seen to be a little cumbersome and has a few issues with security.
• CCM (counter with cipher block chaining message authentication code; counter with CBC-MAC). This is a stream cipher mode and has a similar performance to CBC. It integrates better integrity checks with a MAC (message authentication code).
• ChaCha20. It is not AES — which can be a good thing. Along with this, it is a stream cipher (and so fast in its operation). It is typically not as fast at CTR and GCM, but faster than CBC. Overall, AES tends to be accelerated for its processing on x64/x86 chips, but not for ChaCha20. As with AES GCM mode, ChaCha20 implements AEAD (Authenticated Encryption with Additional Data) and is useful in defending against playback attacks.

There are other modes, such as OFB (Output Feedback) and CFB (Cipher Feedback), but these are not used that much. For this in the finance industry, you might also be using 3DES, and which has not been broken, but is much slower than AES and ChaCha20. Here are some performance tests [here]:

Generally, the stream ciphers can struggle against nonce reuse, and if the same nonce is used, it can be possible to break AES by XOR’ing cipher streams.

And to show the breaking of the integrity of AES:

But, it’s NIST defined!

There is no guarantee that because NIST defines something as a standard that it will be secure, as it all depends on the implementation. ECDSA and EdDSA are NIST standards but have been easily broken in the past with poor implementations.

We have seen that CTR mode is weak against bit-flipping, and where GCM creates a MAC to defend against this. While it is nearly impossible to flip the bits of the cipher and of the MAC, and for them to tie-up, it is certainly possible to recreate a valid MAC and replace it, when a nonce is reused.

So, companies who take security seriously should understand their risks, and test accordingly. Those involved in areas of high risk, such as dealing with financial data and PII, should understand the risks in the methods they implement and not just tick a box to say that they have encrypted the data. I have seen many examples of companies ploughing on with the same old encryption methods — even though they have significant weaknesses.