在填充預言攻擊（CBC）期間，如何獲得明文塊的第一個字節？

想像一下使用 16 字節長度的塊和 PKCS#5 對 CBC 模式進行填充預言攻擊。

一如既往，您開始顯示明文的最後一個字節。然後你迭代地向後移動並到達最後一個明文塊的第一個字節。在這個階段，你已經用 15 個字節欺騙了填充，這些值是0x0f.

• 那麼，既然你沒有填充長度，你如何揭示一個塊的第一個字節？
• PKCS#5 是否允許您用0x10值填充 16 個字節？
• 或者，這些東西取決於特定應用程序中使用的填充的實現？

PKCS#5 是否允許您用0x10值填充 16 個字節？

不，但那是因為 PKCS#5 只為 DES 指定填充，並且具有 8 字節的塊大小。在填充 AES 時，甚至 PKCS#5 本身也引用了 PKCS#7。有關此處差異的更多資訊。

*現在來看看真正的答案。*PKCS#7 填充，與 PKCS#5 相同，但允許任何塊大小，需要0x10 字節值的 16 倍作為填充：

對於此類算法，方法應是在尾端填充輸入 $ k - (l \bmod k) $ 八位字節都有價值 $ k - (l \bmod k) $ ， 在哪裡 $ l $ 是輸入的長度。

這裡 $ k $ 是以字節為單位的塊密碼的塊大小，例如塊大小為 16 字節的 AES。現在顯然如果 $ l $ 是 16 的倍數，然後添加一個完整的填充塊（如 $ l \bmod k $ 將評估為零，因此只有 $ k $ ，即剩下 16 個）。

原因很簡單：想像一個塊大小倍數的純文字消息以有效的填充模式結尾。然後取消填充將刪除該部分消息。通過始終執行填充，無論消息的內容和大小如何，都可以執行取消填充（即允許正確解密任何消息）。

那麼，既然你沒有填充長度，你如何揭示一個塊的第一個字節？

我們沒有超出填充長度。然而，

• PKCS#5 ( rfc 2898 ) 定義為 8 字節塊，即 64 塊大小，如 DES，並且
• PKCS#7 ( rfc2315 ) 定義了最多 256 字節的塊，也涵蓋了 AES。

因此，對於 16 字節塊，假設我們使用的是 PKCS#7。

16 字節塊的填充包含來自 $ \texttt{0x01} $ 至 $ \texttt{0x10} $ . 價值 $ \texttt{0x10} $ 如果消息大小是塊大小的倍數，則使用。

一旦你確定填充是 $ \texttt{0x0F} $ ，然後你繼續尋找下一個案例並要求oracle進行填充 $ \texttt{0x10} $ . 現在詢問第一個字節的各種值?

?,10,10,10,10,10,10,10,10,10,10,10,10,10,10,10

一旦伺服器沒有向您發送填充錯誤，您就確定了第一個字節。$$ (D(C_2) \oplus C’) \gg 15 = \texttt{0x10} $$

實際上，這就是填充預言機攻擊中消息字節的顯示方式。

PKCS#5 是否允許您使用 0x10 值填充 16 個字節？

不，如上所述。PKCS#7 允許大於 8 字節和最多 256 字節的填充塊。

如果消息大小是 16 字節的倍數，則添加一個帶有 16 字節的新塊 $ \texttt{0x10} $ 價值觀。如果未添加新塊，則在刪除填充時可能會導致問題。例如; 如果最後一個字節是 $ \texttt{0x01} $

$$ \texttt{xxxxxxxxxxxxxxx1} $$

然後失去一個字節的消息。

或者，這些東西取決於特定應用程序中使用的填充的實現？

Serge Vaudenay 首次描述的 padding oracle；CBC Padding Applications 對 SSL、IPSEC、WTLS以及多年後多次應用所引發的安全漏洞；

1. 2012 Steam破解 Steam 客戶端密碼學
2. 2013年幸運十三襲擊
3. 2014貴賓犬
4. 2016 Y等 OpenSSL CBC Ciphersuites 中的另一個 Padding Oracle，

填充預言機是協議和實現缺陷的混合體。padding oracle 攻擊會洩漏有關秘密數據的資訊，攻擊者可以將其與精心設計的無效輸入一起使用。攻擊的結果是不僅破壞了最後一個塊的機密性，而且破壞了整個消息的機密性。

encrypt-then-MAC一個好的協議將在範例中使用 MAC

$$ * $$. 在解密之前，伺服器會先檢查 MAC 標籤。如果有錯誤，它將返回一個不正確的標籤。這只會洩漏有關密文的資訊。一個糟糕的協議會以錯誤的順序執行此操作，並且可能會像填充 oracle 攻擊一樣洩露有關明文的資訊。 我們稱 CBC 為古老模式。好的緩解措施是完全擺脫 CBC 模式，就像從 TLS 1.3 中刪除它一樣。在 TLS 1.3 中只有5 個密碼套件，並且它們都經過身份驗證的加密模式；

• TLS_AES_256_GCM_SHA384
• TLS_CHACHA20_POLY1305_SHA256
• TLS_AES_128_GCM_SHA256
• TLS_AES_128_CCM_8_SHA256
• TLS_AES_128_CCM_SHA256

---

$$ * $$ 我們應該先 MAC-then-encrypt 還是先加密-then-MAC？了解更多詳情

引用自：https://crypto.stackexchange.com/questions/76713