使用 iv/salt/iterations 儲存的逐行加密日誌記錄。它有多安全？
我正在建構一個加密的日誌記錄應用程序。日誌條目使用 AES-256-GCM 加密，使用密碼派生密鑰和 PBKDF2。應用程序必須支持日誌輪換，我想讓每個日誌條目“自給自足”。這將允許我丟棄以前已經處理過/太舊的日誌。
自給自足是指擁有日誌條目和密碼就足以解密有效負載。我不希望維護一個單獨的文件/記錄，其中包含有關密鑰或其派生的資訊。
這意味著我必須在每個日誌條目中儲存一大堆資訊：
- pbkdf2鹽
- pbkdf2 迭代
- iv
- gcm 標籤
- 加密有效載荷
PBKDF2 salt 和迭代不太可能經常更改（如果有的話）。IV將為每個日誌條目隨機生成。payload 是使用者提供的內容 tag 是 GCM 加密的驗證標籤。
以下是此類日誌文件的範例：
timestamp pbkdf2 salt iter iv tag encrypted payload 1584815488,IqdD09R5kbtA4recw5LQeg==,100000,IxsZwVEjYvO0vgjl,w4EdRjRJQNCK/sOYKYyXYA==,DCqFFCGQbpYhWEy3u3OlKMN2iMn9JF2vFZFY 1584815488,IqdD09R5kbtA4recw5LQeg==,100000,n1PscNktuug1Os7b,e1oZAg31XCZOZUC4ZrKjzg==,cLhr1baGonaTt/k/PJZ2s5hboTBjNCmqFu281w== 1584815488,IqdD09R5kbtA4recw5LQeg==,100000,RqKtky2ICMORWqGZ,G5VHGDkhWuUch7ZN0AiRBg==,mjexQ9aUHCZGomrlrnQrk6K9ULBEYHPSsjeAxw== 1584815488,IqdD09R5kbtA4recw5LQeg==,100000,JY3h/TQSlk+yP/5W,bXL8xK5QVC9uPi2vJ+IDQw==,xu5e/UKPyeEnghFVJL+JLmV2yXYlN2cKBmGGZw== 1584815488,IqdD09R5kbtA4recw5LQeg==,100000,W/3uKytKkGmPezdP,HuGNKT6L+Bh/bEvwnlkI5A==,rwVB3ssIKNaz0ZldNRR608JKOIjlimnuu5ZAyQ== 1584815488,IqdD09R5kbtA4recw5LQeg==,100000,l7RSko8EvTydWWgt,Ahwjm63IR/8MK03gn//uQQ==,cVS+O0nP7BrhuFCheXn1EDSdGSXumzu8PL1cUQ== 1584815488,IqdD09R5kbtA4recw5LQeg==,100000,H+5ywMwpalZVPwLj,nzVSRSz08gJ+OxcktniAOQ==,4WbpNcfcIEcx0wDyzH7s40u+Utx+xzlIFfosuA== 1584815488,IqdD09R5kbtA4recw5LQeg==,100000,hF5i+nCT3lFFxHJh,w9MYSR4j3tlebur+ZkUyVg==,9ZIlK8ooUhV0AVAJso6DIstAZ3IdxXCbNhpG4A== 1584815488,IqdD09R5kbtA4recw5LQeg==,100000,RAqAaY4cXsAMXZ3m,JzS4uU4QuMeenWqOMnCoRA==,phjLHaBeETJ+H5mRq0i1EUIe/MIbNmxEnNhLcA== 1584815488,IqdD09R5kbtA4recw5LQeg==,100000,iGXfpm7FZ7Rmj0F1,TRi0/ElsdCbdUUGBrhxqhQ==,P2yMW+1pn9F7kTTU7bWOm19xrjWQU+0UuhJGKw== 1584815488,IqdD09R5kbtA4recw5LQeg==,100000,IXNxT6RwDu3BnoFB,7khAMRKSLcE6nAcxdUsQbQ==,FMv3gUuO5Q2HVwetr/uo73ph4UOuA+Z3IOiXEg==
- 將所有這些資訊儲存在同一個地方是否安全？
- 一個日誌文件通常會包含成百上千個這樣的條目。隨著條目數的增加，加密是否會顯著變弱？
- 出於實際原因，時間戳必須以明文形式儲存。但是，我想驗證它沒有被篡改。最好的方法是什麼？
- 將所有這些資訊儲存在同一個地方是否安全？
列出的所有資訊（salt、pbkdf2、迭代、iv、GCM 標籤、加密有效負載）都可以視為公共資訊。我們已經考慮到攻擊者除了知道Kerckhoffs 原理的加密密鑰之外的所有這些知識。
- 一個日誌文件通常會包含成百上千個這樣的條目。隨著條目數的增加，加密是否會顯著變弱？
IV是隨機生成的。如果隨機生成器很弱，那麼它可能會導致 IV 重用，這對於 AES-GCM 來說是一個很大的安全問題，因為底層的 CTR 模式可以通過拖拽顯示明文，甚至更多可能導致偽造品。
可以按照 NIST 800-38d 8.2 IV 結構的建議使用計數器或 LFSR 生成 IV ，這樣它就不會重複。一個更好的主意是半計數器/LFSR 半隨機。
$$ \text{nonce} = \text{random} \mathbin| \text{LFSR} $$ 這可以防止系統故障問題，即計數器/LFSR 的最後階段未儲存，然後可能導致隨機數重複。儘管可能會重複計數器/LFSR 階段，但新的隨機數將防止 IV 重用問題。
AES-GCM 具有 IND-CCA2，它並沒有變弱，尤其是 256 位密鑰大小。但是，在一段時間內更改密鑰可能是個好主意。這可以使用主密鑰和使用HKDF的派生密鑰形式或對 PBKDF2 使用不同的鹽來完成。
- 出於實際原因，時間戳必須以明文形式儲存。但是，我想驗證它沒有被篡改。最好的方法是什麼？
認證加密 (AE) 也稱為帶有關聯數據的認證加密 (AEAD)。您可以提供時間戳作為關聯數據，AES-GCM將在完整性部分使用它。這是為此類目的而設計的。這可以形式化為
$$ (C,T) \leftarrow \operatorname{AES-GCM-}\mathcal{E}^{N,A}_K (M) $$在哪裡
$ \mathcal{E} $ 代表加密， $ K $ 代表鑰匙， $ N $ 代表隨機數， $ A $ 代表相關數據。C是密文，T是認證標籤。同理解密；
$$ (M | \perp) \leftarrow \operatorname{AES-GCM-}\mathcal{D}^{N,A}_K (C) $$在哪裡 $ \mathcal{D} $ 是解密和 $ \perp $ 是標籤不匹配停止。
每條評論更新
如果攻擊者擁有該日誌文件的一行，以及相應的明文負載會怎樣。例如，知道上面範例的第 1 行表示“初始日誌條目”。這會損害密鑰嗎？
AES 是原始的，它應該是一個偽隨機排列。它可以通過使用適當的操作模式與AES一起實現IND-CPA或IND-CCA或認證加密。
我們假設已經解決了 IV 重用，那麼在 AES-GCM 的 CTR 加密中，我們有；
$$ C_i = P_i \oplus \operatorname{AES}(k, \text{nonce}\mathbin|\text{counter}_i) $$這意味著攻擊者將知道明文和密文塊。這實際上是已知的明文攻擊 ( KPA )，並且 AES 被認為是安全的。您還可以在此處閱讀遠離它的對 AES-128 和 AES-256 的可能攻擊。