Block Cipher Modes

Electronic Codebook (ECB)

• Bad because the encoding key repeats. if there is data of a single value to be converted, that repeated value will be output in seemingly random ciphertext, but each block that is outputted will be the same!
• Does not hide structures larger than the size of a single block
• each byte can be one of 256 possibilities
• NOT IND-EAV

Cipher Block Chaining (CBC)

• Following encryptions depend on initial and sub-sequential encryptions
• IV (a nonce value) sent with ciphertext, unencrypted, then used to recover message

• IND-EAV, but NOT IND-CPA

  Counter Mode (CTR)

  Advantage by being able to compute the value to be XOR'd with the message ahead of time - reducing computation during run time.

  • Security Proof
  • Encryption & decryption = same
  • Can be computed in parallel (independent of previous encoding)
  • Pad can be computed offline
  • Random access
  • BUT - cannot be used with small block length ciphers (i.e. 3DES)

Cipher Feedback (CFB) * Output Feedback (OFB) Modes

• Like CBC, but doesn't need a decryption function

XTS

• Specialized for random access apps like full disk encryptions

Offset Codebook (OCB) & Galois\/Counter (GCM)

• For authenticated encryption

ECB - Electronic Code Book. This mode is the simplest, and transforms each block separately. It just needs a key and some data, with no added extras. Unfortunately it sucks - for a start, identical plaintext blocks get encrypted into identical ciphertext blocks when encrypted with the same key. Wikipedia's article has a great graphic representation of this failure.

Good points: Very simple, encryption and decryption can be run in parallel.

Bad points: Horribly insecure.

CBC - Cipher Block Chianing. This mode is very common, and is considered to be reasonably secure. Each block of plaintext is xor'ed with the previous block of ciphertext before being transformed, ensuring that identical plaintext blocks don't result in identical ciphertext blocks when in sequence. For the first block of plaintext (which doesn't have a preceding block) we use an initialisation vector instead. This value should be unique per key, to ensure that identical messages don't result in identical ciphertexts. CBC is used in many of the SSL\/TLS cipher suites.

Unfortunately, there are attacks against CBC when it is not implemented alongside a set of strong integrity and authenticity checks. One property it has is block-level malleability, which means that an attacker can alter the plaintext of the message in a meaningful way without knowing the key, if he can mess with the ciphertext. As such, implementations usually include a HMAC-based authenticity record. This is a tricky subject though, because even the order in which you perform the HMAC and encryption can lead to problems - look up "MAC then encrypt" for gory details on the subject.

Good points: Secure when used properly, parallel decryption.

Bad points: No parallel encryption, susceptible to malleability attacks when authenticity checks are bad \/ missing. But when done right, it's very good.

OFB - Output Feedback. In this mode you essentially create a stream cipher. The IV (a unique, random value) is encrypted to form the first block of keystream, then that output is xor'ed with the plaintext to form the ciphertext. To get the next block of keystream the previous block of keystream is encrypted again, with the same key. This is repeated until enough keystream is generated for the entire length of the message. This is fine in theory, but in practice there are questions about its safety. Block transforms are designed to be secure when performed once, but there is no guarantee that E(E(m,k),k) is secure for every independently secure block cipher - there may be strange interactions between internal primitives that haven't been studied properly. If implemented in a way that provides partial block feedback (i.e. only part of the previous block is bought forward, with some static or weakly random value for the other half) then other problems emerge, such as a short key stream cycle. In general you should avoid OFB.

Good points: Keystream can be computed in advance, fast hardware implementations available

Bad points: Security model is questionable, some configurations lead to short keystream cycles

CFB - Cipher Feedback. Another stream cipher mode, quite similar to CBC performed backwards. Its major advantage is that you only need the encryption transform, not the decryption transform, which saves space when writing code for small devices. It's a bit of an oddball and I don't see it mentioned frequently.

Good points: Small footprint, parallel decryption.

Bad points: Not commonly implemented or used.

CTR - Counter Mode. This essentially involves encrypting a sequence of incrementing numbers prefixed with a nonce (number used once) to produce a keystream, and again is a stream cipher mode. This mode does away with the problems of repeatedly running transforms over each other, like we saw in OFB mode. It's generally considered a good mode.

Good points: Secure when done right, parallel encryption and decryption.

Bad points: Not many. Some question the security of the "related plaintext" model but it's generally considered to be safe.

Padding modes can be tricky, but in general I would always suggest PKCS#7 padding, which involves adding bytes that each represent the length of the padding, e.g. 04 04 04 04 for four padding bytes, or 03 03 03 for three. The benefit over some other padding mechanisms is that it's easy to tell if the padding is corrupted - the longer the padding, the higher the chance of random data corruption, but it also increases the number of copies of the padding length you have. It's also trivial to validate and remove, with no real chance of broken padding somehow validating as correct.

In general, stick with CBC or CTR, with PKCS#7 where necessary (you don't need padding on stream cipher modes) and use an authenticity check (HMAC-SHA256 for example) on the ciphertext. Both CBC and CTR come recommended by Niels Ferguson and Bruce Schneier, both of whom are respected cryptographers.

That being said, there are new modes! EAX and GCM have recently been given a lot of attention. GCM was put into the TLS 1.2 suite and fixes a lot of problems that existed in CBC and stream ciphers. The primary benefit is that both are authenticated modes, in that they build the authenticity checks into the cipher mode itself, rather than having to apply one separately. This fixes some problems with padding oracle attacks and various other trickery. These modes aren't quite as simple to explain (let alone implement) but they are considered to be very strong.