Aes
使用靜態鹽保護 AES IV
我有一個（離線）共享密鑰（對稱），用於加密/解密數據。
現在，此數據屬於後端和前端已知的特定使用者。我的想法是使用使用者名/ID 作為鹽。但是對於 AES，我們只有 iv。
這樣做可以確保只有在正確的使用者登錄時才能加密前端的數據，因為沒有正確的 salt/iv。數據將是無稽之談。
但是這個 iv 將不再是隨機的。
那麼你對我如何處理這個問題有什麼建議嗎？此外，密鑰和使用者名/ID 是兩個端點唯一知道的。
您沒有提到任何必要的分組密碼的操作模式。
- CBC模式需要 IV隨機且不可預測，因此這不是您的方式。
- 點擊率模式需要一個 $ (IV,Key) $ 對永遠不會出現超過一次。絕不能使用相同的 $ (IV,key) $ 再次配對，否則會失去機密性。
CTR 模式一般使用 96 位 nonce 和 32 位計數器來形成 Initial value。如果隨機數再次出現並且計數器重複，則可以通過拖拽來顯示這些塊。隨機數可以隨機選擇，之後有 50% 的碰撞機率 $ 2^{48} $ 隨機隨機數生成。NIST 還推薦基於計數器/LFSR 的隨機數生成。
點擊率模式可以為您提供解決方案。
上述模式只為您提供保密性。我們可以，而且我們應該走得更多；
- GCM為您提供機密性、完整性和身份驗證。由於 GCM 使用 CTR 模式進行加密，因此您將遇到相同的（IV，密鑰）重用問題。
如果 IV 的長度為 92 位，則 $ J_0 =IV || 0^{31} ||1 $ 作為 IV 傳遞到 CTR 模式，其中 32 位用作開始形式的計數器 $ 1 $ . 所以如果你在同一個 key 下重複使用同一個 IV，你在 CTR 模式下也會遇到同樣的問題。
- XChaCha20-poly1305是帶有擴展隨機數的 ChaCha20，我們可以更安全地使用隨機隨機數。它具有 192 位的隨機數大小，並且一旦生成，就有 50% 的機率發生衝突 $ 2^{96} $ 相同密鑰下的隨機隨機數。雖然這有相同的 $ (IV,key) $ 問題得到它的可能性是不會發生的。
- 還有AES-GCM-SIV模式。這是防止隨機數誤用的，即使 IV 相同，模式只會洩漏消息相同。這需要對數據進行額外的傳遞。
因此，可以使用 AES-GCM-SIV 來緩解所有可能的問題或使用 xChaCha20-poly1305。
對於使用者，您應該注意，加密的 IV/nonce 絕不是保密的。它們可以與密文一起儲存，通常在前面。在客戶端加密期間，可以創建它們。因此，使用者不需要知道加密後的 IV/nonce 的任何資訊，伺服器可以將它們與密文一起儲存。使用者只需要密鑰，並且必須始終保密。