在 CTR 模式下重複 nonce
誰能詳細解釋為什麼在 CTR 模式下重複 nonce 是危險的?
兩個案例來解釋
- 當為每個隨機數重複純文字時。
- 當純文字對於每個 nonce 都是唯一的時
.
重用密鑰/隨機數通常會影響 CTR 模式和流密碼的安全性。假設您有兩個使用相同密鑰加密的密文,例如 E(A) 和 E(B)。
E(A) = key xor A E(B) = key xor B
現在嘗試對兩個密文進行異或,如下所示
E(A) xor E(B) = key xor A XOR key xor B = A xor key xor key xor B // algebraic property of xor = A xor 0 xor B // because key xor key yields 0 = A xor B // XORing 0 with anything yields that thing
鑑於 A 和 B 是正常的英文字母,A 和 B 的猜測將是微不足道的,因為您失去了流密碼的密鑰空間。現在,你只是在嘗試 26 個字母。
當 A 和 B 具有相同的長度時,最壞的情況適用。有效地,您將一次破解兩個密文。
這個數學事實是可怕的,並大聲告訴你永遠不要重複使用密鑰
在上傳到雲端之前,我曾經在密碼管理器中使用 ChaCha 對數據庫進行加密。由於 ChaCha 是一種流密碼,因此上述數學事實將適用於我的數據庫的任何兩個版本。現在,我的雲提供商可以對我的數據庫的兩個版本進行異或運算並獲取我的秘密,而無需費心破解密鑰。我將更改我的關鍵密碼並恢復到我的老朋友Twofish。
– 編輯添加 –
每次點擊“保存”時,我的密碼管理器都會更改密鑰。似乎它在其 PBKDF 中使用了一種鹽或其他東西,因為我每次更改條目時都不會更改主密鑰。無需更改舊密碼,因為之前的攻擊會揭示
E(A) xor E(B) = key1 xor A XOR key2 xor B
此外,如果數據庫根本沒有改變,攻擊將只顯示 NULL。
E(A) xor E(A) = 0 // same key and same database
一種擔心是在數據庫完好無損的情況下更改密鑰。這將揭示
E1(A) xor E2(A) = key1 xor A XOR key2 xor A = key1 xor key2
不確定結果是否
key1 xor key2
會幫助攻擊者。如果有人知道,請發表評論。
在計數器模式下,分組密碼作為 PRNG 執行,本質上類似於同步流密碼的密鑰流生成器。密鑰和 nonce 決定了 PRNG 的起點,因此如果 nonce 曾經使用相同的密鑰重用,則生成的密鑰流是相同的。
為什麼這很糟糕?因為如果您找出與使用重複密鑰流加密的一條消息的密文相對應的明文,推導出密鑰流是微不足道的(密文 = 明文 XOR 密鑰流),您可以輕鬆解密使用相同密鑰流加密的任何其他消息。(本質上是已知明文攻擊)。
要回答您的具體問題:
- 如果相同的明文使用相同的隨機數(和相同的密鑰)加密,則密文是相同的。
- 如果明文是“唯一的”(不同的可能更準確),則密文是不同的。但如上所述,如果對手獲得任何明文-密文對的知識,他可以解密所有其他消息。