Add the rest of university notes
This commit is contained in:
366 files changed
+9844
-110
No files matched your search
@@ -0,0 +1,138 @@
|
||||
# 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**
|
||||
- 
|
||||
- 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
|
||||
|
||||
|
||||
|
||||
#### 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
|
||||
|
||||
|
||||
|
||||
- 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
|
||||
|
||||
|
||||
|
||||
> 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
|
||||
|
||||
|
||||
|
||||
- $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$
|
||||
|
||||
|
||||
|
||||
$$
|
||||
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
|
||||
|
||||
|
||||
|
||||
$$
|
||||
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
|
||||
- 
|
||||
- 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
|
||||
|
||||
|
||||
|
||||
#### 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$
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
### 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
|
||||
|
||||
|
||||
|
||||
- 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`
|
||||
|
||||
|
||||
Reference in new issue
Block a user