𝖄𝕺🌎𝕿𝕽𝕺¥

對稱加密中使用操作模式的動機#

對稱加密算法（如 AES）也就是加密和解密過程使用相同的密鑰 key。本身只能安全加密固定大小的數據塊。為了加密任意長度的消息，需要將這些基本算法運用在特定的操作模式中。

• 一個塊狀密碼可加密 N bit 的信息。如果不是 N 的整數倍，不是固定長度，或者類似 TCP 流呢？
• 操作模式提供了使用區塊密碼加密靈活數據量的不同方法。

! CBC 和 CTR 符合 IND-CPA

確定性和完整性？#

Deterministic 確定性：同樣的明文塊會產生同樣的密文塊

Integrity 完整性：確保數據在傳輸或存儲過程中未被篡改的特性。如 CTR 就不是，因為 CTR 模式只提供加密功能，不包括驗證數據未被改動的機制，也就不提供完整性校驗。

ECB（電子密碼本 Electronic Code Book）模式：#

使用塊密碼加密較長信息的最簡單模式，將消息分割成塊獨立加密。其主要缺點是以相同的方式加密（Key k 不變），所以同樣的明文塊會產生同樣的密文塊（這就是確定性），容易泄露信息。不推薦用。

• 可能需要對最後一個塊進行填充。
• 填充容易出錯，需要謹慎處理。塊中出一點錯整個塊解密就錯了。
• 加密可以並行進行。
• 加密是有確定性的，沒完整性。
• 很少用，特例：針對高熵明文空間的可搜索加密。

破解？#

• 建立密碼本，弱密碼易破解
• 密碼不變，再次出現就識別得到，如置換。

CBC（密碼塊鏈接 Cipher Block Chaining）模式#

在加密每個塊（必須完整塊，考慮填充）前，將它與前一個密文塊進行 XOR 操作。這需要一個初始向量（IV）來啟動過程。這增強了安全性，但仍然存在潛在的問題，如可預測的 IV。

• IV 必須是均勻隨機的，否則導致攻擊
• 沒有確定性，沒有完整性
• 必須完整塊 N 的倍數，可考慮填充，同時 N 太小會出問題
• 必須使用不同密鑰，同密鑰多次加密密文塊會導致碰撞 ciphertext block collisions，即已知 Pj 就能恢復 Pi，推倒如下：

CTR（計數器 Counter）模式#

將加密算法轉換為流式加密器。它不直接加密消息，而是加密一個計數器（賦值不同），然後將輸出與明文進行 XOR 操作。這提供了很高的靈活性和並行處理能力。

• 使用遞增計數器 ctr 生成偽隨機輸出塊（將位串 ctr 視為整數，加法 mod 2^n）。
• 可並行運行。
• 在知道明文之前預先計算加密掩碼 Ri。
• 快：分塊密碼通常比專用流密碼設計要慢
• 沒有 Integrity 完整性，且所有流密碼都如此。
• 確定性
• 不需要填充，因為最後一個輸出塊 rN 可以被截斷為精確長度 pN。
• 通常將 ctr 作為密文的一部分發送，如果解密過程可以通過其他方式恢復 ctr，我們可以省略 ctr。
• 加密使用 Enc，解密也使用 Enc：
• 因此，不需要實現 Dec - 事實上，Enc 不需要可逆！
• 從技術上講，這意味著 CTR 模式可以使用一個偽隨機 function 方法而不是偽隨機排列 permutation。

Key 要求#

密鑰安全要求：對於固定的密鑰 k，所有使用的計數器值（在所有加密中）必須是不同的。

• 如果一個計數器是重複的，那麼密文塊的 XOR 將產生明文塊的 XOR。
• 類似於流密碼的一次性密碼笺 / 密鑰流重複使用問題。

Error propagation 传播#

• 密文比特翻轉 bit-flip 可能導致明文比特翻轉。

步驟#

使用不同計數器（ctr）值確保加密的唯一性，具體方法如下選一：

1. 每次加密時 ctr 從 0 開始，更換密鑰（成本較高）。
2. 每次使用隨機的 ctr 開始（需控制密鑰使用以防碰撞）。
3. 記錄上次使用的 ctr 值，下次加 1 使用（需維護狀態）。
4. ctr 由應用提供的固定大小的隨機數（nonce N）和內部計數器組成，每次加密從 0 開始計數（防止 nonce 重複，限制明文大小以防內部計數器溢出）。
   此方法用於 GCM 模式（如下）。

GCM（伽羅瓦 / 計數器模式）#

是 CTR 的變種，增加了數據完整性驗證功能。它廣泛用於保護網絡數據，如 TLS 協議。

• GCM 要求對每個加密和驗證的數據塊進行一次塊密碼運算和一次 128 位的乘法運算。
• 確定性
• 每個塊密碼操作都可並行化。
• 由於加密與驗證無關，軟件實施可通過重疊驗證和加密來提高速度。

對稱加密的 IND-CPA 安全性#

IND-CPA 是認為對稱加密算法安全的一個重要標準，通常通過引入隨機性（如每次加密都使用不同的初始化向量 IV）來實現。

四要素：KeyGen,Enc,Dec,Correctness#

• KeyGen: 均勻隨機
• Enc: key K + plaintext M → output C
  • 一般是隨機的，如 CBC、CTR
  • 後來的 Enc 可以有額外輸入但要有確定性
• Dec: key K + ciphertext C → output M or error
  • 假設有確定性，設可加密的最大明文長度為 L，所以 M 屬於 {0,1}≤L
• Correctness: 求對於所有 k
• K is key space, M is message space, C is ciphertext space
• 密文通常比明文長，但盡量短，減少拓展。

IND 不可區分性 Indistinguishable#

這是一種安全屬性，指的是給定兩個不同的明文，加密算法產生的密文應該使攻擊者無法確定哪個密文對應哪個明文（semantic security 語義安全）。理想情況下，即使攻擊者知道或者可以選擇明文，他們也無法從密文中獲取任何有用信息。

CPA 選擇明文攻擊 Chosen Plaintext Attack#

這是一種攻擊模型，其中攻擊者可以選擇任意數量的明文並獲得它們的密文。攻擊者的目標是利用這些信息來破解加密算法，獲取密鑰或解密其他密文。

屬性#

• IND-CPA 安全性可捕捉信息恢復攻擊：任何能從 c 中恢復 m 的攻擊者都可以轉化為能破解 IND-CPA 安全性的攻擊者。
• IND-CPA 安全性可捕捉密鑰恢復攻擊：任何攻擊者，只要給定一些密鑰對（m, c ），就能恢復密鑰 k、都可以轉化為破壞 IND-CPA 安全性的攻擊者。
• IND-CPA 安全性確保明文的每一位都被隱藏起來。
• 可以證明，如果使用 CBC 模式和 CTR 模式等方案，它們都符合 IND-CPA 安全性定義如果使用良好的塊密碼。

怎麼猜測？#

Padding and padding oracle attacks#

為何填充？#

為了確保明文長度符合加密算法所需的固定塊大小，防止在塊加密中明文長度不足的問題。

• 對於 CBC 模式，填充 - 加密 - 移除填充。
  • 但容易被攻擊，可通過 MAC 實現完整性來檢測修改過的密碼文本，MAC 需要和加密方案結合。
• 可以是隨機，也可以是確定的。
• 需要是 N 的倍數的比特串。
• 可拓展的。

簡單例子對於 AES 的 padding#

對於 AES 算法，其中 N = 128 位，也就是 N/8 = 16 字節。因此，可能添加到消息中的填充字符串（以字節格式）是從 0x01 到 0x0F，具體取決於需要填充的字節數。例如，如果你需要填充 5 個字節來達到下一個 128 位邊界，那麼每個填充字節的值將是 0x04，因為 0x04 是十六進制表示的 5 減去 1。

填充要求#

至少添加一個 byte 字節的填充: 為了使填充機制能夠在解密時被識別和移除，即使消息的長度已經是加密算法所需的塊大小的倍數，也至少添加一個字節的填充。
消息長度是 N 位的整數倍：將添加一個完整的新塊，僅包含填充。
安全性後果：填充可能會引入安全風險，比如填充預測攻擊（Padding Oracle Attack）。

錯誤傳播#

在對稱加密中，一個錯誤的密文塊會導致解密時該塊完全錯誤，並影響下一個塊的一部分，因為錯誤會在解密操作中傳播。

full plaintext recovery attack 全明文恢復攻擊#

全明文恢復目標是從密文中恢復出明文信息，不一定需要恢復出密鑰；它可能僅僅是解密出一個或多個密文。

Padding Oracle Attack 填充預言機攻擊 is a chosen ciphertext attack#

一種安全漏洞。

• 如果 padding 不是預期值之一，則拋出異常，並給出有用的錯誤信息。
• 它利用加密系統處理 padding 錯誤的方式來進行攻擊。比如錯誤信息在網絡或通過日誌可見，或定時行為，會暴露。
• 錯誤可能導致會話終止。
• 密碼文可能有額外限制。（最小 / 最大長度）
• 屬於chosen ciphertext attack CCA 選擇密文攻擊（因為攻擊者需要解密信息），因此不在 IND-CPA 安全模型所涵蓋。
• 導致 full plaintext recovery attack。
• 每個字節 8 比特，8*16 = 128 次嘗試每字節。
• 從塊中的右向左目標字節，逐漸增加有效填充模式的長度。（參見前一頁幻燈片）

例子中使用 0x01，這表示當只差一位填充時。要根據缺少位數改變。

attack_process

Attack on CBC Mode with Predictable IVs#

• 可擴展到 full plaintext recovery 完全明文恢復
• 多年來對 SSL/TLS 記錄協議的首次重大攻擊

BEAST Attack#

• JavaScript 需要能夠在 SSL/TLS 記錄協議的信息的最開始注入其選擇的明文塊。

• JavaScript 還需要與 MITM 攻擊者通信。

• 與同源策略有關的問題。

  

BEAST 攻擊的成功依賴於以下條件：

• 攻擊者能夠在受害者的瀏覽器上運行他們的代碼。
• 使用了容易受到攻擊的協議版本（SSL 3.0 或 TLS 1.0）。
• 使用了可預測的 IV（在 TLS 1.0 中，IV 是前一個密文塊，因此是可預測的）。

BEAST 的後果是什麼？#

• BEAST 令 TLS 非常頭疼。
• 大多數客戶端實施都 "停留" 在 TLS 1.0。
• 最佳解決方案：升級到 TLS 1.1 或 1.2。
• 使用隨機 IV，因此可防止攻擊。
• 但也需要服務器端的支持。
• 對於 TLS 1.0，有多種破解方法：
• 客戶端使用 1/n- 1 記錄分割可以阻斷攻擊。- 在每條真實記錄前發送長度為 0 的虛擬記錄。- 或者改用 RC4？