AES-256 CBC 的 IV 代最佳實踐
我看到一些 SWIFT 程式碼通過從 a-zA-Z0-9 空間中選擇 16 個字元為 AES 256 生成 IV。這安全嗎？足夠安全嗎？
為 AES 256 生成 IV 的最佳實踐是什麼？
0x00從-中選擇隨機 16 個字節0xff會好嗎？我們希望將密鑰和 IV 儲存在數據庫中並檢索它以進行加密/解密。我們希望將其儲存為一串值（即“1, 255, 126, 124 …” - 像這樣的 16 個值）。然後使用解碼的值作為字節解密欄位。
除了確保隨機生成器良好之外，在 IV 生成方面還有什麼需要注意的嗎？
我們想使用 AES-256 CBC。
我看到一些 SWIFT 程式碼通過從 a-zA-Z0-9 空間中選擇 16 個字元為 AES 256 生成 IV。
這安全嗎？足夠安全嗎？
幾乎總是，當您看到現代密碼由字元串初始化時，開發人員並不真正了解密碼對二進制數據進行操作。這是一種具有特殊名稱的開發實踐：字元串化程式碼，其中每個參數都是一個字元串，無論如何。
使用的字元幾乎是基本的 64 位字母表，每個字節使用 6 位。這意味著您擁有 (128 / 8) * 6 = 96 位安全性。我們會原諒遺漏的 64Ki 選項。幸運的是，對於大多數用途來說，這仍然有足夠的 IV 空間。
不過，它確實限制了使用這種隨機 IV 加密的消息數量；保持大約 40 億條消息（ $ 2^{32} $ ) 或更少以獲得高安全性，並且可能一千次 ( $ 2^{42} $ ) 更多，如果你想危險地生活。
更大的問題是我不會相信任何將字元串用作 key 或 IV 的開發人員。那是一個 $ \color{red}{\text{red flag}} $ : 我會開始尋找其他問題，因為這些幾乎肯定會存在。
為 AES 256 生成 IV 的最佳實踐是什麼？
從 0x0-0xff 隨機選擇 16 個字節會好嗎？
是的，這可能是為 CBC 模式生成 IV 的最佳方式。不過，還有其他方法可以做到這一點。然而，對於許多現代模式（基於 CTR 模式），您只需要使用隨機數。在這種情況下，隨機 IV 可能仍然是最好的方法，但計數器也有優勢。例如，計數器不太可能重複（由於生日問題，IV 碰撞的可能性相對較高）。
請確保您使用的是種子良好的加密安全隨機數生成器。
我們希望將密鑰和 IV 儲存在數據庫中並檢索它以進行加密/解密。我們希望將其儲存為一串值（即“1, 255, 126, 124 …” - 像這樣的 16 個值）。比使用它作為字節解密。
這是一個壞主意，因為對於任何模式，IV 都不應該為同一個鍵重複。通常，這是通過將其保留/添加到密文的前綴來實現的。在數據庫中保留密鑰也沒有什麼意義。畢竟，密鑰應該比它試圖保護的欄位更難訪問。
最後，字元串的問題是它們通常很難從記憶體中刪除。通常，一旦不再使用密鑰，您就希望刪除它們。對於 IV 來說，這不是什麼大問題，因為它們可以在不影響安全性的情況下公開。