使用 PKCS#5 破解 Padding oracle 攻擊中的最低明文位
我一直在使用 CBC 操作模式對塊加密算法進行填充 oracle 攻擊的 C 實現。我理解這個概念很好，但我似乎找不到以下問題的答案（儘管在 stackoverflow 和這個網站上查找了類似的問題）：
當我們將在我們操作的塊末尾連接的密文塊發送到填充預言時，為什麼我們假設第一次成功意味著 XOR 操作產生了 1 而不是 2、3、4、5、6 或 7事情？
為了給那些不知道的人添加更多資訊，PKCS#5 是塊大小為 8 字節的明文的填充方案，其中最後一個塊包含
n填充字節數，每個字節包含 valuen。因此，假設我們發送 (C1||C2)，其中 C2 是原始密文，C1 是一個塊，我們的最低字節從 0 到 255 不等，以便從填充預言中獲得成功驗證。在我看來，成功的驗證意味著填充是正確的，即如果只有 1 個填充字節，則生成的明文字節為 1，如果有 2 個，則為 2，依此類推……為什麼這次攻擊的所有實現都假設 Oracle 的第一次成功意味著我們從 oracle 的最後一個字節中獲得了 0x01？是因為在最後一個字節和倒數第二個字節中獲得 0x02 而僅改變最後一個字節的機率較低嗎？如果是，這是否意味著該算法可能無法解碼密文？
為什麼這次攻擊的所有實現都假設 Oracle 的第一次成功意味著我們從 oracle 的最後一個字節中獲得了 0x01？是因為在最後一個字節和倒數第二個字節中獲得 0x02 而僅改變最後一個字節的機率較低嗎？
很大程度上，是的。請記住，我們的一般假設是攻擊者對只在大多數時間有效的攻擊感到滿意。在這種情況下，假設攻擊者沒有關於受到攻擊的明文塊的初始資訊，那麼導致我們具有有效填充的隨機 C1 將對應於機率約為 01 的填充字節 $ 1 - 1/255 $ 的時間。
此外，如果您發現一個 C1 可能會顯示最後一個字節，並且可能有更長的填充模式，那麼有一個非常簡單的測試；嘗試修改倒數第二個字節的 C1；如果它有一個 01 填充字節，則得到的解密仍然有有效的填充，如果是其他任何東西，它都有無效的填充；因此很容易被抓住。