為什麼可以在 AES 中加密同一流中的多個消息
我有一個標準的隨機密鑰和 IV。然後我使用這些密鑰和 iv 創建密碼，然後加密特定消息。稍後，如果我嘗試使用相同的密碼（這意味著相同的密鑰和 iv）加密另一條消息，這是可能的。對此有何解釋？
import os from cryptography.hazmat.primitives.ciphers import Cipher, algorithms, modes key = os.urandom(32) iv = os.urandom(16) cipher = Cipher(algorithms.AES(key), modes.CTR(iv)) encryptor = cipher.encryptor() decrypter = cipher.decryptor() ciphertext1 = encryptor.update(b"secret message") ciphertext2 = encryptor.update(b"I'll give you 100 and that's my last offer") + encryptor.finalize() decrypted_message = decrypter.update(ciphertext1) print("the decrypted message from the cyphertext : ", ciphertext1, " is : ", decrypted_message) decrypted_message2 = decrypter.update(ciphertext2) + decrypter.finalize() print("the decrypted message from the ciphertext : ", ciphertext2, " is : ",decrypted_message2)
您沒有清楚地閱讀您的圖書館的文件。
隨著
cipher.encryptor()您打開流式傳輸，它僅通過該finalize()方法完成。此操作對於處理大文件和流很重要。可以將輸入分成塊，update()多次呼叫方法來處理塊。可以將其稱為會話 $ (IV,key) $ 一直開到你關門！
稍後，如果我嘗試使用相同的密碼（這意味著相同的密鑰和 iv）加密另一條消息，這是可能的。對此有何解釋？
CTR 模式使用 IV 和計數器的組合用於 PRF/PRF (ChaCha/AES) 的輸入以生成 x 流或使用明文生成密文。CTR 模式在某種意義上與現代版 OTP 的主要區別在於；OPT 具有完美的保密性，而 CTR 具有 Ind-CPA（對計算受限的對手的放鬆）。
一旦初始化CTR 模式，對於每個塊加密，計數器都會遞增。根據庫，計數器可以是 32 位或 64 位。
像 OPT 這樣的 CTR 模式會出現災難性的故障，如果 $ (IV,key) $ 對被重複使用。攻擊者可以嘗試使用嬰兒床拖動技術來破壞機密性。
在您的情況下，更新繼續使用它所在的 CTR 模式。那裡唯一的危險，你可能會耗盡危險開始的計數器。
為什麼可以在 AES 中加密同一流中的多個消息
你根本沒有
encryptor()用finalize(). 正如文件所說；
- 一旦 finalize 被呼叫，這個對象就不能再被使用並且 update() 和 finalize() 將引發一個 AlreadyFinalized 異常。
您需要
finalize()並選擇一個新的 $ IV $ 或者 $ key $ 並用它創建一個新的加密器。Cipher或者更好的是，在清除前一個實例後創建一個新實例。額外：如何使用 CTR 模式加密多條消息
CTR 模式中的一個鍵 $ IV $ 可以使用很長時間。由於nonce不長，使用隨機 $ IV $ 由於生日限制，可能會產生碰撞。如果使用 64 位隨機 $ IV $ ’s 和 AES 的 64 計數器，您應該在加密之前停止 $ 2^{32} $ 同一鍵下的消息。
正確的推薦方法是對 IV 使用計數器/LFSR（參見NITS 800-38a 附錄 C），以免發生衝突。唯一的問題是系統故障，您可能會失去 LFSR/計數器的跟踪。在這種情況下，請使用統一隨機選擇的新密鑰。
您可以繼續使用流來加密多條消息，但是，這很危險，給加密增加了不必要的風險。
正確的方法是使用新的 $ (IV,key) $ 為每條消息配對。
CTR 模式只能給你 Ind-CPA。在現代密碼學中，我們想要的不僅僅是 Ind-CPA。身份驗證加密 (AE)（與關聯數據 (AEAD)）是現代標準，並且仍在不斷發展。我們有;
- AES-GCM，和
- ChaCha20-Poly1305
TLS 1.3中都存在的密碼。兩種密碼套件都是 AEAD 模式，可以在組合模式下為您提供機密性、完整性和身份驗證。
- AES-GCM 內部使用 CTR 模式加密數據，所以 $ (IV,key) $ 那裡仍然有問題。為了緩解這種情況，有 SIV 模式，AES-GCM-SIV將消息合併到 IV 中以解決此問題。
- ChaCha20 內部有 CTR 模式（PRF 到 CTR）並且有同樣的問題。為了緩解這種情況，我們使用xCHaCha20-Poly1305啟用 192 位隨機數，以便隨機 $ IV/nonce $ 碰撞不會發生。
在所有情況下，使用 256 位密鑰進行加密以減輕可能的加密量子電腦。
您在這裡只加密一條消息，即
secret messageI'll give you 100 and that's my last offer.您選擇了未經身份驗證的 AES-CTR。在這種模式下，AES 用於生成偽隨機比特流，該流簡單地與明文比特逐一異或。因此，當您將密文的前 14 個字節傳遞給解密函式時，您將得到前 14 個字節的明文。
未經身份驗證的加密是危險的，CTR 尤其如此。事實上這個模組的文件說
這是一個“有害物質”模組。僅當您 100% 絕對確定自己知道自己在做什麼時才應該使用它，因為該模組充滿了地雷、龍和帶有雷射槍的恐龍。相反，您可能對Fernet（對稱加密）感興趣。
如果您使用 Fernet，那麼您將無法像這樣將消息分成兩部分解密。