變化的明文會補償固定的初始化向量嗎？
這是AES ECB 和 CBC 模式在保護靜態數據方面的相對優點的後續問題。
我需要將加密的個人帳號 (PAN) 儲存在數據庫中。我唯一可用的加密選項是具有固定 (0x00) IV 的 CFB 模式。我可以選擇我的密碼，並選擇了 AES-256。
無需應用程序“知道”密鑰即可執行加密和解密，密鑰安全地儲存在“其他地方”。
在本練習中，PAN 是 16 字節數字（16 個十進制數字）；我目前正在解決的攻擊是盜竊數據庫副本，其中包含所有加密的 PAN，其中任何一個都可以重複。
我完全理解使用常量 IV 是一個弱點，但這超出了我的控制範圍。
以下任何選項是否會減輕弱點？：
- 我有一個可用的 8 字節二進制時鐘，其內容每微秒或更長時間改變一次，並且每 130 年重複一次。我在加密之前將此時鐘添加到明文 PAN，並在解密後將其丟棄。
- 相同的，除了我預先設置和丟棄兩個副本，以完成第一個 16 字節塊。
- 我生成 8 個字節的隨機數據並預先添加。
- 我生成 16 個字節的隨機數據並預先添加，
具體來說，我想知道：
一種。16 字節是否足夠，而 8 字節不夠？
灣。隨機字節是否足夠，而 µsec 時鐘不夠？
C。這些選項是否完全彌補了固定 IV 的弱點？
冒著鞭打一匹死馬的風險，在出色的答案之後（尤其是來自@DW）發表了一些額外的評論
- 我一直同意“不要自己動手”的原則，但現在，更是如此。
- 我認為有必要指出這些“消息”永遠不會傳輸，而只是“靜止”儲存，而我在本練習中要防禦的攻擊是“他們竊取了我的數據庫”。所以我不確定是什麼
- DW 所選擇的明文攻擊真是讓人大開眼界。
- 在這種情況下（輸入、收費、儲存，也許檢索退款），我想更好地了解身份驗證會給我帶來什麼好處。
- 我歡迎進一步評論將 TOD 時鐘用作 IV。以下是一些額外的細節：
- TOD 時鐘是 64 位整數，表示自 1900 年 1 月 1 日 00:00 以來經過的時間。
- 時鐘以這樣一種方式更新，即第 51 位保證每微秒更新一次。位 0-51 是經過的微秒的無符號數。
- 在速度更快的機器上，52-63 範圍內的位也會以相應的頻率更新。
- 有問題的系統在單個真實機器上作為單個圖像執行。
- 時鐘同步不太可能使時鐘倒退，但讓我們分析一下這種情況：
- 如果在峰值時我每秒進行 100 次加密（實際數字要少得多），我假設最慢的時鐘（每秒 1M）。讓我們假設時鐘撥回 5 秒（我認為這是非常極端的。順便說一下，它是格林威治標準時間，所以沒有夏令時）
- 現在，我將生日悖論應用於 500 萬次中的 1000 次加密 (5*(100+100))；兩個或多個同義詞的機率小於 1.3E-7
具有固定 IV 的 CFB？哎呀！那是完全不安全的：對於明文的前 16 個字節，它甚至比 ECB 模式更糟糕，這說明了一些問題。請去啟發誰認為將其作為唯一可用的加密模式（甚至是多個選項中的一個）公開是個好主意。
讓我詳細說明。聽起來基線是使用具有固定全零 IV 的 CFB 模式來加密 16 字節（一個塊）消息。在這種情況下，PAN 的加密 $ P $ 將會
$$ C = E_K(0) \oplus P. $$ 該公式將用於每個 PAN 的加密。注意 16 字節的值 $ E_K(0) $ 是解密所需的唯一秘密——並且給定一個明文/密文對，您可以輕鬆恢復 $ E_K(0) $ 通過公式 $ E_K(0) = P \oplus C $ . 因此，給定一個有效的 PAN 及其相應的加密，我可以解密所有其他 PAN。例如，如果我知道自己的 PAN，並且我的 PAN 被加密儲存在數據庫中的某個位置，並且我得到了數據庫的副本，那麼我就可以解密其他人的 PAN。這不好！這突出了為什麼你必須做某事。
這就是為什麼密碼學家對“不要自己動手”如此重視的原因，以及為什麼他們建議您使用經過嚴格審查的高級方案，例如 GPG 用於加密靜態數據或 TLS 用於加密動態數據。
您提到了一些可能的解決方法。如果您使用隨機的 16 字節前綴，上述問題就會消失，因為您已經將其渲染為基本上等同於帶有隨機 IV 的 CFB 模式。是的，這行得通。
不，8 字節前綴是不夠的：它會使 PAN 的前 8 個字節不受保護並且容易受到我上面描述的攻擊。
根據您的編輯，包含時鐘值的 16 字節前綴聽起來可能沒問題。通常，我對依賴時鐘值的唯一性持謹慎態度，因為時鐘值可能重複（例如，因為您在兩個不同的 VM 中執行軟體的兩個副本，或者因為您在一個VM 並執行檢查點和回滾，或者因為 NTP 調整了您的時鐘並且您的時鐘向後執行了一段時間——是的，它可能發生）。聽起來你已經解決了這些問題。我可能仍然有點謹慎，因為使用時鐘對軟體的部署方式更敏感（對於某些運維人員來說，將來某天很容易將軟體轉移到雲或虛擬化環境中，而無需意識到這可能會使您的安全分析無效）。
/dev/urandom）。但是，如果有其他限制使時鐘更可取，那麼使用時鐘可能會沒問題。無論您使用什麼作為前綴，您仍然會失去數據的身份驗證。我總是建議使用經過身份驗證的加密，而不是普通加密。在這種情況下，我很難確定身份驗證的好處。（它有助於防止篡改數據庫中的數據，如果攻擊者獲得了讀取/寫入數據庫的能力，但不會以其他方式損害您的軟體的完整性——但目前尚不清楚這在實踐中是否重要。）所以，讓我預先承認，在這種情況下，我無法立即看到忽略身份驗證的任何嚴重風險。也就是說，作為設計原則，我喜歡盡可能簡化安全分析。如果添加身份驗證使我不必認真考慮是否存在身份驗證很重要的任何場景，我’ 通常只是反射性地應用身份驗證，因為它通常實際上是免費的（或者比嘗試仔細考慮缺乏身份驗證的後果更便宜）。這可能只是個人特質/風格。