mirror of
https://github.com/calofmijuck/blog.git
synced 2025-12-06 22:53:51 +00:00
feat: internet security midterm notes (#128)
* [PUBLISHER] upload files #114 * [PUBLISHER] upload files #115 * PUSH NOTE : 1. OTP, Stream Ciphers and PRGs.md * PUSH ATTACHMENT : mc-01-prg-game.png * PUSH ATTACHMENT : mc-01-ss.png * [PUBLISHER] upload files #116 * PUSH NOTE : 03. Symmetric Key Cryptography (2).md * PUSH ATTACHMENT : is-03-feistel-function.png * PUSH ATTACHMENT : is-03-ecb-encryption.png * PUSH ATTACHMENT : is-03-cbc-encryption.png * PUSH ATTACHMENT : is-03-cfb-encryption.png * PUSH ATTACHMENT : is-03-ofb-encryption.png * PUSH ATTACHMENT : is-03-ctr-encryption.png * [PUBLISHER] upload files #117 * PUSH NOTE : 01. Security Introduction.md * PUSH ATTACHMENT : is-01-cryptosystem.png * [PUBLISHER] upload files #118 * [PUBLISHER] upload files #119 * [PUBLISHER] upload files #120 * [PUBLISHER] upload files #121 * [PUBLISHER] upload files #122 * [PUBLISHER] upload files #123 * PUSH NOTE : 07. Public Key Cryptography.md (#124) * fix: links fixed * [PUBLISHER] upload files #125 * PUSH NOTE : 08. Public Key Infrastructure.md * PUSH ATTACHMENT : is-08-certificate-validation.png * [PUBLISHER] upload files #126 * PUSH NOTE : 09. Transport Layer Security.md * PUSH ATTACHMENT : is-09-tls-handshake.png * [PUBLISHER] upload files #127 * PUSH NOTE : 08. Public Key Infrastructure.md * PUSH ATTACHMENT : is-08-certificate-validation.png * fix: fixed internal, external links
This commit is contained in:
GitHub
@@ -28,8 +28,8 @@ attachment:
|
||||
### Modules
|
||||
|
||||
- **S-box**: a substitution module
|
||||
- Usually for confusion
|
||||
- $m \times n$ lookup box is needed, since it should be invertible
|
||||
- Usually for confusion, also gives diffusion
|
||||
- $m \times n$ lookup box is used for implementation
|
||||
- **P-box**: a permutation module
|
||||
- Usually for diffusion
|
||||
- Compared to the number of input bits,
|
||||
@@ -42,28 +42,28 @@ attachment:
|
||||
- Standardized in 1979.
|
||||
- Block size is $64$ bits ($8$ bytes)
|
||||
- $64$ bits input $\rightarrow$ $64$ bits output
|
||||
- Key is $56$ bits, but there are $8$ bits representing parity, so total of $64$ bits
|
||||
- Every $8$th bit is a parity bit
|
||||
- Key is $56$ bits, and every $8$th bit is a parity bit.
|
||||
- Thus $64$ bits in total
|
||||
|
||||
### Encryption
|
||||
|
||||
1. From the $56$-bit key, generate $16$ different $48$ bit keys $k_1, \dots, k_{16}$.
|
||||
2. The plaintext message goes through the P-box.
|
||||
3. The output goes through $16$ rounds, and in the round $i$, key $k_i$ is used.
|
||||
2. The plaintext message goes through an initial permutation.
|
||||
3. The output goes through $16$ rounds, and key $k_i$ is used in round $i$.
|
||||
4. After $16$ rounds, split the output into two $32$ bit halves and swap them.
|
||||
5. The output goes through the inverse of the P-box from Step 1.
|
||||
5. The output goes through the inverse of the permutation from Step 1.
|
||||
|
||||
Let $L_{i-1} \parallel R_{i-1}$ be the output of round $i-1$, where $L_{i-1}$ and $R_{i-1}$ are $32$ bit halves. Also let $f$ be the Feistel function.
|
||||
Let $L_{i-1} \parallel R_{i-1}$ be the output of round $i-1$, where $L_{i-1}$ and $R_{i-1}$ are $32$ bit halves. Also let $f$ be the Feistel function.[^1]
|
||||
|
||||
In each round $i$,
|
||||
In each round $i$, the following operation is performed:
|
||||
|
||||
$$
|
||||
L_i = R_{i - 1}, \qquad R_i = L_{i-1} \oplus f(k_i, R_{i-1})
|
||||
L_i = R_{i - 1}, \qquad R_i = L_{i-1} \oplus f(k_i, R_{i-1}).
|
||||
$$
|
||||
|
||||
#### The Feistel Function
|
||||
|
||||
|
||||
|
||||
|
||||
The Feistel function takes $32$ bit data and divides it into eight $4$ bit chunks. Each chunk is expanded to $6$ bits using a P-box. Now, we have 48 bits of data, so apply XOR with the key for this round. Next, each $6$-bit block is compressed back to $4$ bits using a S-box. Finally, there is a (straight) permutation at the end, resulting in $32$ bit data.
|
||||
|
||||
@@ -108,10 +108,10 @@ Thus $F$ and $G$ are inverses of each other, thus $f$ doesn't have to be inverti
|
||||
Also, note that
|
||||
|
||||
$$
|
||||
G(L_i \parallel R_i) = F(L_i \oplus f(R_i) \parallel R_i),
|
||||
G(L_i \parallel R_i) = F(L_i \oplus f(R_i) \parallel R_i).
|
||||
$$
|
||||
|
||||
so evaluating the decryption round is actually equivalent to running the encryption round with upper/lower $32$ bit halves swapped. Hence the reason for swapping each $32$ bit halves.
|
||||
Notice that evaluating $G$ is equivalent to evaluating $F$ on a encrypted block, with their upper/lower $32$ bit halves swapped. We get $L_i \oplus f(R_i) \parallel R_i$ exactly when we swap each halves of $F(L_i \parallel R_i)$. Thus, we can use the same hardware for encryption and decryption, which is the reason for swapping each $32$ bit halves.
|
||||
|
||||
## Advanced Encryption Standard (AES)
|
||||
|
||||
@@ -130,7 +130,7 @@ Each round consists of the following:
|
||||
- **AddRoundKey**: XOR with round key
|
||||
|
||||
The first and last rounds are a little different.
|
||||
- Before the first round, AddRoundKey is done.
|
||||
- AddRoundKey is done before the first round.
|
||||
- The last round does not have MixColumns.
|
||||
|
||||
The objectives of AES:
|
||||
@@ -138,7 +138,7 @@ The objectives of AES:
|
||||
- Code must be compact, and should run fast on many CPUs
|
||||
- Design must be simple
|
||||
|
||||
### Modules
|
||||
### Layers
|
||||
|
||||
#### SubBytes
|
||||
|
||||
@@ -157,7 +157,7 @@ The objectives of AES:
|
||||
- For each column, each byte is replaced by a value
|
||||
- The value depends on all 4 bytes of the column
|
||||
- Each column is processed separately
|
||||
- Thus effectively, it is a matrix multiplication (Hill cipher)
|
||||
- Thus effectively, it is a matrix multiplication (Hill cipher).[^2]
|
||||
|
||||
#### AddRoundKey
|
||||
|
||||
@@ -171,7 +171,7 @@ These 4 modules are all invertible!
|
||||
- Why is there a AddRoundKey at the beginning?
|
||||
- Why is the last round different?
|
||||
|
||||
Both are for engineering purposes, to make the encryption and decryption process the same. (Check!)
|
||||
Both are for engineering purposes, to make the encryption and decryption process the same.[^3]
|
||||
|
||||
## Modes of Operations
|
||||
|
||||
@@ -179,14 +179,14 @@ AES, DES use fixed block size for encryption. How do we encrypt longer messages?
|
||||
|
||||
### Electronic Codebook Mode (ECB)
|
||||
|
||||
|
||||
|
||||
|
||||
- Codebook is a mapping table.
|
||||
- For the $i$-th plaintext block, we use key $k$ to encrypt and obtain the $i$-th ciphertext block.
|
||||
- **Uses the same key for all blocks**
|
||||
- Adjacent blocks are independent of each other.
|
||||
- Advantages
|
||||
- Good when run in parallel
|
||||
- Fast when run in parallel
|
||||
- Limitations
|
||||
- Repetitions in messages (if aligned with the block) may lead to repetitions in the ciphertext
|
||||
- Susceptible to *cut-and-paste attacks*
|
||||
@@ -198,7 +198,7 @@ Since the same key is used for all blocks, once a mapping from plaintext to ciph
|
||||
|
||||
### Cipher Block Chaining Mode (CBC)
|
||||
|
||||
|
||||
|
||||
|
||||
- Two identical messages produce to different ciphertexts.
|
||||
- This prevents chosen plaintext attacks
|
||||
@@ -234,8 +234,8 @@ Since the same key is used for all blocks, once a mapping from plaintext to ciph
|
||||
- If the IV is the same, then the encryption of the same plaintext is the same.
|
||||
- Thus IVs should be random.
|
||||
- IV are not required to be secret, but
|
||||
- No IVs should be reused under the same key
|
||||
- IV changes should be unpredictable
|
||||
- **No IVs should be reused under the same key**
|
||||
- **IV changes should be unpredictable**
|
||||
- On IV reuse, same message will generate the same ciphertext if key isn't changed
|
||||
- If IV is predictable, CBC is vulnerable to chosen plaintext attacks.
|
||||
- Define Eve's new message $m' = \mathrm{IV} _ {\mathrm{E}} \oplus \mathrm{IV} _ {\mathrm{A}} \oplus g$, where
|
||||
@@ -248,12 +248,12 @@ Since the same key is used for all blocks, once a mapping from plaintext to ciph
|
||||
|
||||
### Cipher Feedback Mode (CFB)
|
||||
|
||||
|
||||
|
||||
|
||||
- The message is treated as a stream of bits; similar to stream cipher
|
||||
- **Result of the encryption is fed to the next stage.**
|
||||
- Standard allows any number of bits to be fed to the next stage
|
||||
- It is most efficient to use all $64$ bits (CFB-64)
|
||||
- It is most efficient to use all bits.
|
||||
- Initialization vector is used.
|
||||
- Same requirements on the IV as CBC mode.
|
||||
- Should be randomized, and should not be predictable.
|
||||
@@ -277,13 +277,13 @@ Since the same key is used for all blocks, once a mapping from plaintext to ciph
|
||||
- CFB mode is self-recovering.
|
||||
- 1 bit error in the ciphertext corrupts some number of blocks.
|
||||
- Bit errors in the ciphertext will cause bit errors at the same position.
|
||||
- Since this ciphertext is fed to the next block, the error is propagated
|
||||
- Since this ciphertext is fed to the next block, the error is propagated.
|
||||
- Some implementations (like CFB-8) use shift registers, so errors will be propagated as long as the erroneous bit is in the shift register.
|
||||
- If the error is removed from the shift register, it automatically recovers.
|
||||
|
||||
### Output Feedback Mode (OFB)
|
||||
|
||||
|
||||
|
||||
|
||||
- Very similar to stream cipher.
|
||||
- Initialization vector is used as a seed to generate the key stream.
|
||||
@@ -316,14 +316,39 @@ Since the same key is used for all blocks, once a mapping from plaintext to ciph
|
||||
|
||||
### Counter Mode (CTR)
|
||||
|
||||
|
||||
|
||||
|
||||
- Without chaining, we use a counter (typically incremented by $1$).
|
||||
- Counter starts from the initialization vector.
|
||||
- Highly parallelizable.
|
||||
- Can decrypt from any arbitrary position.
|
||||
- Counter should not be repeated for the same key.
|
||||
- Suppose that the same counter $ctr$ is used for encrypting $m_0$ and $m_1$.
|
||||
- Encryption results are: $(ctr, E(k, ctr) \oplus m_0), (ctr, E(k, ctr) \oplus m_1)$.
|
||||
- Then the attacker can obtain $m_0 \oplus m_1$.
|
||||
|
||||
## Modes of Operations Summary
|
||||
|
||||
|Criteria\Modes|ECB|CBC|CFB|OFB|CTR|
|
||||
|:-:|:-:|:-:|:-:|:-:|:-:|
|
||||
|IV|-|Yes|Yes|Yes|Counter|
|
||||
|Encryption Parallelizable|Yes|No|No|Yes\*|Yes|
|
||||
|Decryption Parallelizable|Yes|Yes|Yes|Yes\*|Yes|
|
||||
|Random Read Access|Yes|Yes|Yes|No|Yes|
|
||||
|Self-Recovering|-|Yes|Yes|-|-|
|
||||
|
||||
- OFB is parallelizable only if the keystream is generated in advance.
|
||||
- We don't have to consider self-recovery if the ciphertext is not fed into the encryption of the next block.
|
||||
- Errors in the ciphertext are not be propagated for ECB, OFB and CTR.
|
||||
- **Random read access**
|
||||
- Suppose that a part of the plaintext changes.
|
||||
- In OFB, the *whole* keystream must be recalculated to fix the ciphertext.
|
||||
- But for other modes, only a part of the ciphertext needs to be changed, using the information from the previous block if necesary.
|
||||
|
||||
---
|
||||
|
||||
Images are from [Wikipedia](https://en.wikipedia.org/wiki/Block_cipher_mode_of_operation).
|
||||
|
||||
[^1]: Some people call this function the *mangler* function.
|
||||
[^2]: Over the finite field $\mathrm{GF}(2^8)$.
|
||||
[^3]: See also a helpful [question](https://crypto.stackexchange.com/questions/1346/why-is-mixcolumns-omitted-from-the-last-round-of-aes) on cryptography SE.
|
||||
|
||||
Reference in New Issue
Block a user