不需要時使用 AES PKCS5 填充

我正在使用帶有 PKCS5 Padding 的 AES/ECB（根據我的閱讀，PKCS7 Padding 實際上在內部使用）和 PBKDF2(HMAC-SHA256) 來加密 Java 中的一些密碼。我輸入一個密碼，該密碼通過 PBKDF2 並獲得一個雜湊值，我將其用作加密密鑰。PBKDF2 設置為輸出 128b 密鑰。

我意識到，每當我輸入錯誤的密碼時，我都會收到“BadPaddingException”錯誤。我想，PBKDF2 的輸出應該足夠長，不能被填充（128b）。即使它被填充，所有密碼（即使是錯誤的）的填充也不應該相同嗎？

為什麼會這樣？

不，這不是 PBKDF2 的輸出大小。問題是當您輸入錯誤的密碼時，PBKDF2 會為您生成具有正確密鑰大小的錯誤密鑰。當您執行密文解密時，庫將測試 PKCS#7 填充在明文上的有效性。由於密鑰不正確，您將收到一條垃圾消息，其中填充部分也是垃圾。圖書館正在拋出BadPaddingException. 以一些低機率，你不會得到任何例外，但填充將是正確的。喜歡 $ (1/256) $ 你最後會得到的機率01，這將是有效的填充，儘管消息是垃圾。這就是為什麼你也需要誠信。

你不應該使用ECB模式，這是不安全的，洩漏模式，甚至我們不稱之為操作模式。

PKCS#7 填充也容易受到網路上的填充預言攻擊。返回錯誤的填充不是一個好主意。

如果您想擺脫填充，可以使用完全不需要任何填充的 CTR 模式。CTR 模式將塊密碼轉換為無需填充的流密碼。同樣，CFB 和 OFB不需要填充/

實際上，所有上述模式，ECB、CTR 和包括 CBC，都是分組密碼的一種古老的操作模式。在現代密碼學中，我們使用並建議經過身份驗證的加密模式，如 AES-GCM 和 ChaCha20-Poly1305。它們以捆綁的形式為您提供機密性、完整性和身份驗證。AES-GCM 內部使用 CTR 模式。

**注 1：**在 GCM 模式下，切勿重複使用 IV/nonce。結果可能是災難性的。

**注2：**即使無法訪問加密密鑰，也可以對明文應用填充，即填充機制獨立於加密。只有塊大小是必需的。反過來，它可以從明文中刪除。

**注3：**如果padding不好的原因不清楚，那麼原因可以；

1. IV 不正確：編碼/解碼問題或根本沒有傳輸？
2. 密鑰不正確：輸入了錯誤的密鑰或使用了不正確的 KDF 密碼。
3. **編碼：**通過網路以二進製而不是 base64 或類似編碼發送的數據。二進制數據可能會混淆某些協議。
4. 數據損壞：消息在傳輸過程中損壞，您沒有任何機制可以檢測到它。

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