Skip to main content

Section 2.9 Block Ciphers

Block ciphers takes the data in, in blocks and use cipher blocks of the same size to perform the encryption. It is very popular and there are many secure algorithms to choose from. Unfortunately if the input data doesn’t fit neatly into blocks of the same size, padding may be required, which takes up more space/memory and reduces the speed of the cipher. As such the block encryption is often less performant than stream encryption.

Subsection 2.9.1 Block Cipher Modes of Operation

There are several ways you can create your cipher blocks and depending on how you do it, various attacks are possible:

Subsubsection 2.9.1.1 Electronic Codebook (ECB)

Diagram showing Electronic Codebook (ECB) mode encryption where multiple plaintext blocks are independently encrypted with the same key.
The image, captioned ’ecb’ and also titled ’Electronic Codebook (ECB) mode encryption’ below the diagram, illustrates how ECB mode operates on multiple blocks of plaintext.
It displays three identical, parallel encryption processes. In each instance, a ’Plaintext’ block, represented as a sequence of conjoined squares, is shown as input to a rectangular unit labeled ’block cipher encryption’. A ’Key’ is also depicted as an input to this encryption unit. The output from each encryption unit is a ’Ciphertext’ block, similarly represented as a sequence of conjoined squares.
This visual arrangement emphasizes that each block of plaintext is encrypted independently of other blocks, using the same key for every block. A key characteristic highlighted by this method is that identical plaintext blocks will result in identical ciphertext blocks.
Figure 2.9.1. Electronic Codebook (ECB) Mode Encryption’
WhiteTimberwolf (SVG version)
 1 
commons.wikimedia.org/wiki/File:ECB_encryption.svg
, Public domain, via Wikimedia Commons
The simplest mode of operation, data is divided into blocks and each block is encoded using a key. Since the blocks are encoded the same way, identical blocks will give identical ciphertexts. This makes it easier, given enough data, to determine what the key is.

Subsubsection 2.9.1.2 Cipher block chaining (CBC)

Diagram of Cipher Block Chaining (CBC) mode of block cipher encryption.
The diagram, captioned ’cbc,’ illustrates the Cipher Block Chaining (CBC) mode of operation for block ciphers. It typically shows plaintext blocks being processed sequentially.
An Initialization Vector (IV) is depicted being XORed with the first plaintext block before it undergoes encryption with the key. For all subsequent blocks, the ciphertext generated from the encryption of the *previous* block is shown being XORed with the current plaintext block before it is encrypted. This chaining dependency is a key visual feature, ensuring that identical plaintext blocks produce different ciphertext blocks.
Figure 2.9.2. Diagram of Cipher Block Chaining
WhiteTimberwolf (SVG version)
 2 
commons.wikimedia.org/wiki/File:CBC_encryption.svg
, Public domain, via Wikimedia Commons.
Starting with an initialization vector (IV) each block is XORed with part of the ciphertext of the previous block to create a chain of ciphertext that is constantly changing. This means that identical blocks will result in different ciphertexts. This is the most common mode of operation, its weaknesses being that the algorithm cannot be run in parallel (sorry modern processors) and that the IV is a common attack target.

Subsubsection 2.9.1.3 Counter (CTR)

Diagram illustrating Counter (CTR) mode encryption with nonce and incrementing counter per block.
The image, captioned ’ctr’ and also titled ’Counter (CTR) mode encryption’ below the diagram, illustrates the Counter (CTR) mode of block cipher operation. It shows three parallel examples of encrypting a plaintext block, each with an incrementing counter value.
In each depicted instance, a ’Nonce’ (e.g., ’c59bcf35...’) is combined with a ’Counter’ (sequentially ’0000000’, ’0000001’, ’0000002’). This combined value is input to a ’block cipher encryption’ unit, along with a ’Key’. The encrypted output of this unit is then XORed (symbolized by ⊕) with a ’Plaintext’ block to produce the corresponding ’Ciphertext’ block.
The diagram highlights that the same nonce is used for these blocks while the counter value increments for each, a mechanism that allows for parallel encryption of blocks. The generation of the keystream (encrypted nonce-counter) is shown as distinct from its application to the plaintext via XOR.
Figure 2.9.3. Counter (CTR) Mode Encryption
WhiteTimberwolf (SVG version)
 3 
commons.wikimedia.org/wiki/File:CTR_encryption_2.svg
, Public domain, via Wikimedia Commons
Instead of using an IV, CTR uses a nonce (random number that is the same for all blocks) and counter. The counter is incremented with each block, meaning this mode can function in parallel. CTR mode solves the problems of ECB while still providing an algorithm that can run quickly on modern machines.

Subsubsection 2.9.1.4 Galois/Counter Mode (GCM)

Diagram of Galois/Counter Mode (GCM) showing parallel encryption via CTR and authentication tag generation.
The image, captioned ’gcm’ and titled ’Galois/Counter Mode (GCM)’, details an authenticated encryption mode. It illustrates an Initialization Vector (IV) used with a series of incrementing counters (Counter 0, Counter 1, Counter 2). Each counter is encrypted with a key (EK). This encrypted counter output is then XORed with corresponding Plaintext blocks (Plaintext 1, Plaintext 2) to produce Ciphertext blocks (Ciphertext 1, Ciphertext 2), demonstrating the Counter (CTR) mode portion of GCM.
In parallel, the diagram shows the authentication mechanism. Authenticated Data (Auth Data 1) and the generated Ciphertext blocks are processed through several Galois field multiplication steps (multH). The lengths of the authenticated data and ciphertext (len(A) || len(C)) are also included in this process. The cumulative result is XORed with the encrypted output of the first counter (EK(Counter 0)) to generate the final ’Auth Tag’.
This diagram effectively visualizes how GCM combines CTR mode for encryption with a GHASH function for authentication, thereby providing both data confidentiality and integrity.
Figure 2.9.4. Diagram of Galois/Counter Mode (GCM)
Gallois Counter Mode block diagram with initialization vector, adapted from a diagram by NIST
 4 
commons.wikimedia.org/w/index.php?curid=74845777
is used under CC0 1.0
 5 
creativecommons.org/publicdomain/zero/1.0/deed.en
.
GCM uses a counter like CTR, but does not make use of a nonce. Instead an IV is used with the inititial counter. GCM also generates a message authentication code (MAC) for each block to verify the integrity of the block. This combination makes for a modern, robust algorithm that is gaining rapid adoption.
Example 2.9.5. Case Study: Exploiting Non-Rolling Codes.
The importance of non-repeating codes, such as the counter codes used in the CTR and GCM block cipher modes of operation can be highlighted through analysis of another important technology that uses codes: keyless entry systems. When garage door openers first came on to the market, the remote would broadcast a single code that the receiver was programmed to recognize as correct. This meant that anyone listening in could easily get the code and replay the code to open the garage door with their own device. (In actuality the code space was so small that you could even easily create a device to cycle through all possible codes in under a minute.)
To combat this, companies began using rolling codes
 6 
en.wikipedia.org/wiki/Rolling_code
in their remotes and receivers. Given the same seed a rolling code allows each device to generate a sequence of codes that are exactly the same. The remote will use the next code in a sequence every time the button is hit. The receiver will validate the recieved code if it matches any of the next several codes in the sequence (in case the button was hit a few times out of range). This effectively mitigates the replay attack.
Given that this was implemented in the 1980s with garage door remotes, you would assume car manufacturers employ the same technology in their remotes. In a case of "everything old is new again" this isn’t true. Blake Berry (HackingIntoYourHeart) discovered that several makes and models of cars are actually still vulnerable to a replay attack.
 7 
github.com/HackingIntoYourHeart/Unoriginal-Rice-Patty/blob/main/README.md
Sammy Kamkar also discovered a vulnerablility for rolling codes, named RollJam, which he demonstrated at DEF CON 23. Kamkar’s device jams signals sent by a keyfob, while recording the codes being sent. Once it has two codes recorded, presumably from the victim pressing the button multiple times, it stops jamming, sends out the first code to unlock the car and stores the second code to unlock the car at a later time.
You have attempted 1 of 1 activities on this page.