Padding

PKCS7 填充的安全性

  • February 4, 2022

我剛剛設計了自己的填充函式,並提出了一個可能損害加密安全性的潛在問題。在我修復了這個缺陷之後,我發現 PKCS7 標準填充也應該容易受到已知明文攻擊。如果我在任何時候錯了,請糾正我。

PKCS7 用填充的總字節數填充每個填充字節。每次,至少附加一個字節的填充,在最壞的情況下是整個塊。當我在電子密碼本模式下操作密碼時,可以很容易地猜出最後一個塊進行已知明文攻擊。(在 1 出 16

$$ block size $$情況下,立即)範例填充如下所示。

53 65 63 72 65 74 20 74 65 78 74 2e --> 53 65 63 72 65 74 20 74 65 78 74 2e 04 04 04 04

我認為用隨機廢話填充所有填充字節並用填充字節數填充最後一個字節會更加安全。為什麼在如此廣泛分佈的填充標準中不是這種情況?下面的例子不是更安全嗎?

53 65 63 72 65 74 20 74 65 78 74 2e --> 53 65 63 72 65 74 20 74 65 78 74 2e 5a 2c 12 04

提前致謝。

我認為用隨機廢話填充所有填充字節並用填充字節數填充最後一個字節會更加安全。為什麼在如此廣泛分佈的填充標準中不是這種情況?下面的例子不是更安全嗎?

53 65 63 72 65 74 20 74 65 78 74 2e --> 53 65 63 72 65 74 20 74 65 78 74 2e 5a 2c 12 04

這基本上稱為ISO 10126 填充,與ANSI X9.23 填充兼容。

首先,應該注意的是,填充預言攻擊只是更廣泛的明文預言攻擊的一部分。因此,如果解密後的明文會產生任何錯誤,那麼當系統嘗試應用明文時也會出現同樣的問題。例如,使用 XML 解碼器的錯誤很容易創建明文預言機攻擊。更簡單:如果明文塊由左側的填充組成,那麼顯然它也無法通過填充預言攻擊。

其次,現在將接受密文(即不產生填充錯誤)256 / 8 = 32 次中的 1 次(最終字節被賦值0108)而不是大約 256 次中的一次(最終字節被賦值01或最終字節被賦值02 02ETC。)。這排除了使用填充來實現消息完整性/真實性。

第三,你已經減輕了 padding oracle 攻擊,但你還沒有完全消除它。畢竟,最後一個字節仍然需要評估。如果可以從原始明文中學到任何東西,我們就認為密碼被破壞了。

最後,您還沒有消除填充成本。


如果您仍然承擔成本,那麼您不妨添加一個身份驗證標籤,該標籤是通過使用 MAC 或經過身份驗證的密碼創建的。這就是我們對填充屬性不太感興趣的原因。我們可以使用不需要填充的模式,添加身份驗證標籤並擁有具有更好安全屬性的密碼模式,同時限制消息擴展。

引用自:https://crypto.stackexchange.com/questions/98493