在AES加密中填充隨機數據有什麼好處嗎？

Question

使用AES加密時，必須將明文填充到密碼塊大小。大多數庫和標準使用填充，其中填充字節可以由未填充的明文長度確定。在可能的情況下使用隨機填充字節有什麼好處？

我正在實施一個存儲敏感的每用戶和每會話數據的方案。數據通常是JSON編碼的鍵值對，並且可能是短而重複的。我期待PKCS#5的指導，但我計劃使用AES加密算法而不是DES3。我計劃在每個數據項上隨機選擇一個IV，並根據需要確定一個由用戶ID和密碼或會話ID確定的密鑰。

讓我感到驚訝的一件事是明文的PKCS＃5填充方案。爲了將密文填充到8字節塊，在末尾添加1到8個字節，填充字節內容反映了填充字節的數量（即，01,0202,030303，直到0808080808080808）。我自己的填充方案是在明文前面使用隨機字節，並且明文的最後一個字符是添加的填充字節數。

我的推理是在AES-CBC模式下，每個塊都是前面塊的密文的函數。這樣，每個明文都會有一個隨機性元素，爲我提供了另一層來自已知明文攻擊的保護，以及IV和關鍵問題。由於我的明文預計會很短，所以我不介意將整個解密的字符串保存在內存中，並將正面和背面的填充切片填充。

一個缺點是相同的無襯墊明文，IV和密鑰會導致不同的密文，使得單元測試變得困難（但並非不可能 - 我可以使用僞隨機填充發生器進行測試，並且密碼強度更高生產）。

另一種情況是，爲了實施隨機填充，我必須添加至少兩個字節 - 一個計數和一個隨機字節。對於確定性填充，最小值爲一個字節，或者與明文或密文包裝器一起存儲。由於像PKCS＃5這樣廣受好評的標準決定使用確定性填充，所以我想知道是否還有其他我錯過的東西，或者我認爲太高的好處。

Answer 1

兩者，我懷疑。好處是相當少的。

您忘記了獲取或生成密碼質量隨機數的運行時成本。在一個極端情況下，當有限的隨機性可用（例如，某些系統上的/ dev/random）時，您的代碼可能需要等待很長時間以獲得更多的隨機字節。

另一方面，當您從PRNG獲取隨機字節時，如果您使用相同的隨機源生成密鑰，則可能會使問題暴露出來。如果您一個接一個地向多個收件人發送加密數據，則已向前一個收件人提供了有關PRNG狀態的大量信息，這些信息將用於爲您的下一個通信會話選擇密鑰。如果你的PRNG算法被破壞了，那麼IMO比完全AES上的明文攻擊更可能會比你使用故意確定的填充更糟糕。

無論哪種情況，您都可以獲得填充，但它比PKCS＃5填充更具計算密集性。

順便說一下，使用例如壓縮數據壓縮可能重複的數據是相當標準的。在加密之前放氣;這減少了數據中的冗餘，這可能使某些攻擊更難執行。

最後一項建議：使用只有用戶名和密碼不同的機制來派生密鑰非常危險。如果您要使用它，請確保您使用沒有已知缺陷的散列算法（不是SHA-1，而不是MD-5）。 cf this slashdot story

希望這會有所幫助。