Block ciphers (like DES and AES) can be used directly only for a single block of plaintext. However, typically we want to encrypt plaintext that is much longer than a single block. The Block cipher modes is to issue this point and illustrates how to use a block cipher to do that securely.
Property
A good block mode should have the following properties.
1.Security: Identical plaintexts block shouldn't produce identical ciphertext blocks.
2.Security: There should be protection against deletion or insertion of blocks.
3.Recovery: Ciphertext transmission errors should affect only the block containing the error.
4.Efficiency: It should be efficient(e.g., parallelisable)
ECB
Just simplest way: Apply the encryption block by block. This is called Electronic Codebook mode, ECB.
Decryption just does the operation in reverse, and uses decryption function of the block cipher.
Property analysis
1. ECB produce identical ciphertext block from identical plaintext block(one-one,not random),so ECB fails property 1.
2. Also fail property 2 since all the blocks is encrypted separately, blocks can be inserted or deleted arbitrarily.
3.Satisfies 3 and 4 (error only affect one block containing the error and can be parallelisable)
CBC
CBC add random "initialisation vector" (IV) to randomise (xor) the first plaintext block, and then use the encrypted ciphertext block to randomise (xor) next plaintext block.
Notice: The IV should be randomly chosen for each encryption. Note that you must store the IV with the ciphertext, otherwise it's not possible to decrypt. Thus, the IV is random, but not secret. Since the ciphertext include the IV, it is one block longer than the plaintext. That's a small expansion in size.
Property Analysis
1.Satisfy. The random IV is chosen to randomize block for each encryption, which means that two same block from two message will produce different ciphertext block definitely.
2.Satisfy. The ciphertext block will not be decrypted successfully to original plaintext if we insert or delete one ciphertext block.
3.Satisfy. Just two block(the block containing error and the next block ) changed.
4.Fail. The encryption for one block depends on previous ciphertext block, so it cannot be parallelisable.
CTR
In counter mode, we don't chain the blocks together, but still we aim to make idential plaintext blocks have different ciphertext blocks. To encrypt a message, we choose a random nonce, and then set up a counter which is incremented for each block.
The nonce must be stored with or transmitted with the ciphertext blocks. Thus, similarly to CBC, CTR mode increases the size of the ciphertext by one block.
Property Analysis
1.Satisfy. The nonce is random for every encryption for one message which guarantee the identity for same blocks in different messages. The counter plus one after encryption for each block which guarantee the identity for same blocks in one message.
2.Satisfy. If block deleted or added, the counter will changed for decryption, which results in decryption failure.
3.Satisfy. it is encrypted separately.
4.Satisfy. Reason same as 3, so it can be parallelisable.
Question? CTR does not satisfy diffusion. is it SECURE?
A variation of CBC that is not secure
Let (E , D) be a secure block cipher, and let E be encryption using the following variation of CBC mode:
Each time an encryption is done, the IV that is used is the previous IV plus 1. (In CBC, one should use a random IV each time. Here, we are simply incrementing the IV used last time, instead of taking a fresh random one.)
Explain why this is insecure?
We can just modify the the plaintext of the first block to make it xor wth IV product same as that of the first block encrypted last time. And we can get the same ciphertext as before.
Considering IND-CAP game, attacker can get the ciphertext of m1 and m2 ,which is same as the last time, so attacker can distinguish which message the challenger provide easily.