隨機數據CBC填充方案？
在 CBC 模式下使用 AES 時，當最後一個明文塊沒有密碼所需的長度時，需要填充。比方說 $ k $ 將需要模式字節來填充塊。我的想法是用 $ k-1 $ 隨機字節後跟一個對應於整數值的字節 $ k $ （或者 $ k-1 $ ）。也就是說，它告訴添加了多少填充。解密時，前一個解密的塊被保留，直到很明顯它不是倒數第二個塊。如果是，則相應地刪除填充並獲得完整的純文字。
這是填充消息的安全方式嗎？更一般地說，這種填充方法可能會出現問題，或者不正確的填充方案會損害密碼嗎？
填充是危險的。帶有填充的 CBC 模式對於選擇明文攻擊是安全的，在這種攻擊中，對手可以說服合法方加密消息並獲取密文。但是對於選擇密文攻擊通常是不安全的，在這種攻擊中，對手可以製作密文並獲取有關相應明文的資訊。具體來說，填充往往容易受到填充預言攻擊，其中攻擊者發送特製密文並沒有獲得相應的明文，而是找出密文中的填充是否有效。攻擊者可能會發現，例如，因為如果密文無效，解密器會發出錯誤消息，或者因為解密器沒有執行它將對有效消息執行的操作，或者因為解密器需要不同的數量處理具有有效或無效填充的消息的時間。
填充預言攻擊的破壞性取決於填充的性質以及對手可能知道多少部分明文。一個著名的例子是幸運十三攻擊，其中允許最多 256 個字節的填充和在消息頭中具有 13 個字節的已知明文的結合導致了針對未受保護的實現完全解密 TLS 連接的實際攻擊在許多現實場景中。
在您的情況下，攻擊者的機會更加有限，但該計劃仍然容易受到攻擊。假設對手知道或可以猜到一個塊中明文的前 15 個字節，並且想知道最後一個字節。攻擊者可以將要解密的塊發送為 16 字節消息，並至少了解最後一個字節是否為有效值（1 到 16）。這不是完全違反保密規定，而是違反保密規定。
填充預言攻擊依賴於對手學習填充是否正確。防禦是沒有任何無效的填充。對您的方案的一個簡單調整具有此屬性：使最後一個字節的前 4 位也隨機。這種方式沒有填充是無效的，因此沒有填充oracle攻擊是可能的。然而，攻擊者可能仍然能夠了解明文的長度（例如通過非常精確地測量處理所需的時間），如果密文是攻擊者製作的，那麼這個長度實際上可能是一個機密字節的消息。
要獲得真正的安全密碼，您需要使用經過身份驗證的加密。認證加密不易受到選擇密文攻擊，因為攻擊者無法偽造表面上有效的密文：所有有效密文都包含一個認證標籤，沒有密鑰就無法計算。您可以通過獲取未經身份驗證的密文並添加 MAC（“encrypt-then-MAC”）來建構經過身份驗證的加密，即使加密部分填充了 CBC，它也可以工作。關於這個主題，請參閱我們應該 MAC-then-encrypt 還是 encrypt-then-MAC？. 但是，CBC 與流模式相比沒有優勢，所有常見的正確認證加密模式都使用 CTR 模式作為加密部分。
您的填充定義不完美，看看為什麼；
- 什麼時候 $ k=0 $ 這意味著最後一個塊已滿，您需要告知添加了一個新塊。新塊有 15 個隨機字節，最後一個字節是
0x0F現在它已經完成了。
只要分組密碼像 AES-CBC 一樣是 CPA 安全的，那麼已知明文攻擊就沒有問題。
當我們轉向填充預言攻擊時，它實際上是一個解密預言，可用於揭示所有明文，而不是加密密鑰。乍一看，您的填充方案不容易受到填充 oracle 攻擊。
這是填充消息的安全方式嗎？
它似乎比已經是標準填充方案的 PKCS#7 更好。正確的方法是不使用適用於 padding oracle 的CBC 模式。使用不需要填充的流模式，如 CTR 模式。或者，更好地切換到現代操作模式；帶有 AES-GCM 和 ChaCha20-Poly1305 等相關數據的身份驗證加密模式都存在於 TLS 1.3 中，它們不需要填充。它們可以為您提供機密性、完整性和身份驗證。
更一般地說，這種填充方法可能會出現問題，或者不正確的填充方案會損害密碼嗎？
看不出它適用於padding oracle攻擊。AES-CBC 是 CPA 安全的，密鑰洩露沒有問題。
這個填充的一個有趣的問題是，如果攻擊者刪除最後一個塊，你的填充很容易接受任何設置作為填充，而 PKCS#5 有一個特殊的結構，如果最後一個塊被刪除，必須幸運的是有效的填充. 是的，發送長度是一種對策。
我仍然建議忘記 CBC 模式，僅使用靜態數據。