# Padding Oracle Attacks

#### Block Cipher Modes

- Most messages don’t come in convenient 128-bit block lengths
- We’ll need to run a block cipher repeatedly on consecutive blocks
- Why not use stream ciphers?
  - Historically stream ciphgers have proven harder to implement

##### Padding

- ECB and some other modes require message length to be a multiple of the block size
- Public Key Cryptography Standards `PKCS7` is a common padding scheme:
  1. Padding bytes are always added to the plaintext **before it is encrypted**
  2. Each padding byte has a *value equal to the total number of padding bytes* that are added
  3. The total number of padding bytes is **atleast one**
- ![1646749511.png](img/1646749511.png)
- Note in this example there are 7 `7`s and 16 `16`s
- Note the bottom left example there is 1 `1`. This could be interpreted as 1 bytes of padding or some plaintext. This is why every block must contain at least one padding byte

### Electronic Code Book Mode (ECB)

- Just encrypt each block one after another
- This is quick as can be easily parallelised

![1646749909.png](img/1646749909.png)

#### Weaknesses

- If $x_1$ and $x_3$ are the same, then $y_1$ and $y_3$ are also the same.
- ECB allows an attacker to infer information on the plaintext
- Consider a hypothetical bank transfer between two banks that use a fixed key, where the message format is roughly known

![1646750135.png](img/1646750135.png)

- If we start splicing parts of messages together, we can send a legitimate looking message to the bank
- We could also use a chosen plaintext attack by requesting a bank transfer, finding our bank account info and splicing that with another message
- ECB divulges whenever messages or blocks are the same

![1646750265.png](img/1646750265.png)

> Here the RGB pixel data of this image has been encrypted using AES in ECB mode

### Deterministic vs Probabilistic Encryption

- An encryption scheme is **deterministic** if some plaintext is mapped to a fixed ciphertext if the key is unchanged
- ECB is deterministic, but most modern modes of operation of **probabilistic**
- Probabilistic encryption schemes add randomness to the encryption process to achieve a non-deterministic generation of the ciphertext

![1646750428.png](img/1646750428.png)

- $r$ is not a secret

#### Cipher Block Chaining (CBC)

- `XOR` the output of each cipher block with the next input
- $IV$ - **Initialisation Vector**
  - The initial random seed that randomises the whole stream
  - If you encrypted the same plaintext later it will be different
  - An attacker will be unable to tell if $y_1$ and $y_2$ are the same message but with different $IV$ or different messages with different $IV$

![1646750496.png](img/1646750496.png)

$$
y_1 = e_k(x_1 \oplus IV) \\
y_i = e_k(x_i \oplus y_{i-1})
$$

##### CBC Decryption

- Similar to encryption, but now `XOR` takes place after decryption
- This is much easier to parallelise

![1646750796.png](img/1646750796.png)

$$
x_1 = d_k(y_1) \oplus IV \\
x_i = d_k(y_i) \oplus y_{i-1}
$$

- If we lost $y_1$ we would be unable to decrypt $y_2$
  - We would be able to decrypt $y_3$ though

##### Weaknesses

- CBC was the primary method of encryption for many  years
  - Now it is less common
- ![1646750960.png](img/1646750960.png)
- If you flip the first bit in $y_2$, the same bit is flipped for $x_3$
  - Changing $y_2$ means $x_2$ no longer decrypts properly

### Padding Oracles

- Here, an **oracle** is a system we can query and it will tell us if, once decrypt, some text has **valid padding**
- A system is unlikely to tell you directly, but it might give away some clue
- Image an example `api` that receives a CBC encrypted authorisation token

![1646751224.png](img/1646751224.png)

#### Padding Oracle Attacks

- Lets look at a single decryption block in CBC
- The attack is essentially the same for multiple blocks, just one at a time
  - You attack the last block, which contains the padding

> The general strategy is to manipulate bits in the IV to find valid padding and recover $z_i$

![1646751533.png](img/1646751533.png)

![1646751658.png](img/1646751658.png)

![1646751676.png](img/1646751676.png)

![1646751843.png](img/1646751843.png)

### Counter Mode (CTR)

- Encrypt a nonce + counter and use this to mask the plaintext with `XOR`
  - This is very easily parallelised
  - Each block is encrypted differently, avoiding the issues with ECB mode

![1646751954.png](img/1646751954.png)

- We are now using our block cipher as a stream cipher
  - The keystream generation (AES) is run through blocks
- Decrypting is super easy, just the reverse

### Galois Counter Mode

- Extends counter mode to add authenticity
  - The sender definitely sent that message and it hasn’t been modified
- Very similar to ocunter mode, but **adds authentication tag**
  - Uses multiplication in a Galois Finite field $GF(2^{128})$ modulo $x^{128} + x^7 + x^2 + x + 1$
- Extremely parallelsiable
- Robust to message modification
- Is now standard in `TLS1.3`

![1646752433.png](img/1646752433.png)