如何正確實現原型 encrypt-then-MAC AES-CTR + HMAC 模式密碼？
我在 Python 中創建了一個 AES 實現作為學習經驗（主要用於加密/解密文件），並希望確保我的邏輯沒有犯任何重大錯誤（當然，實現是另一回事）。
分組密碼的操作模式是 CTR。該實現支持 AES-128、AES-192 和 AES-256（預設）。
AES 密鑰和 HMAC 密鑰是使用帶有 SHA-256 的 hashlib 的 pbkdf2_hmac 和一個隨機的 16 字節鹽（我創建一個 64 字節密鑰並將每個密鑰分成兩半；對於 AES-128，我創建一個 32 字節的密鑰並將其分成兩半）。
CTR IV 由一個隨機的 8 字節 nonce 和一個從 0 開始的 8 字節計數器創建。salt 作為密文的第一個塊寫入，然後是 CTR IV 作為第二個塊。
最後，使用 HMAC 密鑰和 SHA-256 創建密文的 32 字節 HMAC 值，並將其作為密文的最後兩個塊（32 字節）寫入。
解密時，會在解密之前將 HMAC 值與密文的其餘部分進行檢查。
這個邏輯有問題嗎？從密碼學的角度來看，弱點在哪裡？
謝謝！
您正在描述使用 AES-CTR 進行加密和 HMAC 用於 MAC 的 encrypt-then-MAC。這確實導致了經過身份驗證的加密。
密鑰派生功能可能有更好的選擇，但我對這些選項不是很熟悉，所以我會讓其他人評論。我不明白為什麼在派生密鑰時要加鹽 KDF。這只是意味著您需要為每個密文重新設置密鑰。在某些方面，重新設置密鑰對安全性更好（可能不是在這裡使用低熵密碼作為密鑰的種子），但通常人們為了性能而喜歡避免重新設置密鑰。
IV 只是 $ 8 \text{ bytes} = 64 \text{ bits} $ ，所以你會在加密後開始期待衝突 $ 2^{32} = $ 幾十億的密文。這對我來說似乎不太好。你投入了一個完整的 $ 8 \text{ bytes} = 64 \text{ bits } $ 到櫃檯。你真的需要支持密文嗎？ $ 2^{64} $ 塊長？IV+計數器長度之間的更好平衡將是可取的。例如，使用 12 字節 IV 和 4 字節計數器，可以避免高達 2^48 的 IV 衝突，並且可以支持以下密文 $ 2^{32} $ 塊長（ $ 2^{32} \times 128 \text { bits } = 0.5 \text{ terabits} = 64 \text{ gigabytes} ). $