AES CTR：隨機 IV
我想使用帶有隨機 IV 的 AES CTR，因為這對我來說是最簡單的方法。我有一個加密模組，它支持真正的隨機數生成。由於兼容性，我必須使用 AES CTR。該模組還支持單片計數器，但它的最大值非常低，對於我的案例來說可能太低了。
RFC 3686規定如下：
我必須確保 IV 永遠不會重複，這對於隨機數來說是不正確的，因為它可能會重複。我的密鑰沒有改變。 我找到了這個執行緒，因此聲明使用隨機數（在這種情況下為 128 位）是一種簡單的方法，因為衝突不太可能發生。
我的計數器塊將僅包含 64 位隨機數 (IV)，為塊計數器保留 32 個字節，為靜態設備標識符 (Nonce) 保留 32 個字節。新隨機 IV 的生成只會在設備重啟和塊計數器溢出時發生，這兩個事件都很少發生。這極大地減少了碰撞的可能性，但是，機會仍然存在。
我的問題是：
- 是否有官方文件指出，使用隨機 IV 作為固定密鑰是一種有效的方法（不僅僅是這樣的答案:)）
- 如果不是，您認為這種方法有效嗎？
提前致謝並致以最誠摯的問候
- 是否有官方文件指出，使用隨機 IV 作為固定密鑰是一種有效的方法（不僅僅是這樣的答案:)）
NIST 800-38a說明了您的需求並記住問題發生的時間 $ (key,IV) $ pair 被重複使用，或者更準確地說，在同一個鍵下任何 $ (IV||counter) $ 組合。如果使用隨機 IV 則可能發生後者，然後在相同的密鑰下，兩條消息在不同的位置發生碰撞。
800-38a 給出了兩種方法
- 順序生成
在第一種方法中，對於給定的密鑰，所有明文消息都按順序加密。在消息中，相同的固定集合 $ m $ 計數器塊的位由標準遞增函式遞增。初始明文消息的初始計數器塊可以是任何字元串 $ b $ 位。任何後續消息的初始計數器塊都可以通過將標準遞增函式應用於固定的集合來獲得 $ m $ 前一個消息的最後一個計數器塊的位。實際上，所有在給定密鑰下加密的明文消息都連接成一條消息；因此，明文塊的總數不得超過 $ 2^m $ . 應建立程序以確保保持最新加密消息的最終計數器塊的狀態，並確保消息的正確排序。
簡而言之，在計數器 left+1 不超過 $ 2^m $
- 隨機數
滿足跨消息唯一性的第二種方法是為每條消息分配一個唯一的字元串 $ b/2 $ 位（四捨五入，如果 $ b $ 是奇怪的），換句話說，一個消息隨機數，並將消息隨機數合併到消息的每個計數器塊中。領先的 $ b/2 $ 位（四捨五入，如果 $ b $ 是奇數）每個計數器塊將是消息隨機數，標準遞增函式將應用於剩餘的 $ m $ 位為消息的計數器塊提供索引。因此，如果 $ N $ 是給定消息的消息隨機數，那麼 $ j $ 計數器塊由下式給出 $ T_j = N || [j]_m $ ， 為了 $ j = 1…n $ . 塊數， $ n $ , 在任何消息中必須滿足 $ n < 2^m $ . 應該建立一個程序來確保消息隨機數的唯一性。
簡而言之，這是每條消息遞增的隨機數。
該文件中沒有提到隨機生成，它也是一個舊文件。在 AES-GCM NIST 800-38d中，建議使用帶有計數器/LFSR 的隨機 nonce 或增量 nonce，記住 AES-GCM 使用 CTR 模式和 92 位 nonce 32 位計數器的組合。92 位隨機數在隨機中使用比 64 位 IV 更安全，因為衝突機率很低。
我們簡單地將碰撞機率近似為 50% 的平方根。因此我們可以說 64 位隨機數在之後有 50% 的衝突機率 $ 2^{32} $ unifrom 隨機隨機數生成。實際上，在對手的意義上，這是不可忽視的，必須提前停止。在 96 位的情況下，需要生成均勻隨機 $ 2^{48} $ 隨機數達到 50%，並且應該採取相同的對抗方法。要查看有關衝突的更多詳細資訊，請參閱密碼散列的生日問題，101。由 fgrieu。
- 如果不是，您認為這種方法有效嗎？
由於您的密鑰永遠不會改變，因此加密後有 50% 的衝突機率 $ 2^{32} $ 消息，您將遇到（密鑰，IV）重用問題，您加密的越多，您將擁有的越多。
正如我所看到的，您的兼容性是點擊率而不是它的使用方式。您可以按照 GCM 的建議使用順序 IV，這將使您最多可以加密 $ 2^{64} $ 密鑰下的消息或刪除 IV 的設備標識符並使用隨機生成，在這種情況下，您將在加密後以 50% 的機率發生衝突 $ 2^{48} $ 消息。
只有當每個加密的 16 字節塊的 IV 都發生變化時，第一個語句才是正確的。然而，IV 僅在重新啟動和阻止計數器溢出時發生變化。還有一點需要注意：重啟後會有 10 秒的延遲，因此以這種方式生成新的 64 位 IV，需要 (2^32 * 10s) / ( 60 * 60 * 24 * 365)s = 1360 年才能達到2^32 條消息。但是，通過將塊計數器減少到 2 個字節，將 IV 增加 2 個字節確實是一種選擇。
你說我在 2^32 條消息後發生 50% 的衝突。您是否考慮過 32 位塊計數器？
這取決於計數器的使用方式，假設 nonce 僅使用一次。
只有當每個加密的 16 字節塊的 IV 都發生變化時，第一個語句才是正確的。然而，IV 僅在重新啟動和阻止計數器溢出時發生變化。還有一點需要注意：重啟後會有 10 秒的延遲，因此以這種方式生成新的 64 位 IV，需要 (2^32 * 10s) / ( 60 * 60 * 24 * 365)s = 1360 年才能達到2^32 條消息。但是，通過將塊計數器減少到 2 個字節，將 IV 增加 2 個字節確實是一種選擇。
消息大小為 1 到 3 個塊（16 個字節），有不同的消息，但其中很多會一遍又一遍地重複。
這樣，您最多可以使用計數器 $ 2^{32}/3 \approx 2^{28} $ 消息而不更改 IV。應該注意的是，要使用它，您需要在系統上儲存最後使用的位置 +1。
系統故障
在系統故障期間，可能無法正確儲存它，這可能導致重用 olf 位置。在這種情況下，建議使用新的隨機數生成，因為這已經需要重新啟動，所以這裡沒有問題。