使用 AES-CTR 是否需要將塊輸入實現為 nonce ||櫃檯？
我正在查看一個 AES-CTR 實現（WebCrypto），它需要一個初始化參數
count，它是一個 16 字節的數組。然後它會要求您指定length，或者有多少位專用於計數器（其餘位將充當隨機數。）因此，如果您指定例如長度 = 32，則塊輸入將為隨機數（96 位）|| 計數器（32 位）。然後它說計數器應該足夠大以至於它不會換行。我的問題是為什麼不直接使用完整的 128 位作為隨機數 AND 計數器。用一個隨機的 128 位值初始化它並遞增整個事物，只要你不一直包裹到你開始的地方，那麼一切都很好。
https://developer.mozilla.org/en-US/docs/Web/API/AesCtrParams#Properties
CTR 模式將偽隨機函式 (PRF)（和偽隨機排列 (PRP)）轉換為流密碼。像任何流密碼一樣，這種模式容易受到（密鑰、隨機數）對重用問題的影響，這可能會破壞機密性。這並不意味著使用密鑰被洩露，CTR 模式是 CPA 安全的。
我的問題是為什麼不直接使用完整的 128 位作為隨機數 AND 計數器。用一個隨機的 128 位值初始化它並遞增整個事物，只要你不一直包裹到你開始的地方，那麼一切都很好。
這比 nonce||counter 更成問題，因為
- 必須保存計數器的目前狀態，您最終可能會使用相同的計數器相互發送消息，失敗！。
- 在系統故障期間，您可能最終也會使用舊值失敗。在這種情況下，請更換新密鑰。
如果按順序生成 96 位隨機數，系統故障也會影響。在這種情況下，交換新密鑰是必須的。 3. 第二個問題是，當隨機生成隨機數以備將來在同一個鍵下使用時，不同隨機數的隨機數增量可能會重疊。這是隨機值遞增而不是使用從 0 開始的單獨計數器部分的直接結果。
**對於短消息，**這是一個非常低的機率，如果提供的 nonce 不等於 96 位大小，則在 AES-GCM 中會發生這種情況。請注意，GCM 將大小限制為 $ 2^{32} $ 塊。
在 (96||32) 中，只有生日計算是針對隨機生成的 nonce 的碰撞。nonce+counter 的安全界限很難推導出來。 4. 此外，nonce 值可能會接近 $ 2^{128} $ 這意味著數字將四捨五入。這也具有較低的機率，尤其是對於較短的消息。對於大小為 $ 2^{32} $ 塊，它有 $ 1/2^{96} $ 圍捕發生的機率。 5. 長消息區分符；如果 CTR 模式是用 AES 之類的 PRP 初始化的，那麼在生日悖論（攻擊）之後，將至少有兩個相同的消息塊 $ 2^{n/2} $ 50% 機率的消息塊。這可能是 GCM 保持在下方的原因之一 $ 2^{32} $ 每個 (key,IV) 對的塊。這將使
$$ (2^{k})^2/2^{n}/2=2^{2k-n-1} $$
和 $ k=32 $ 和 $ n=128 $ 那個近似的 $ 2^{-65} $ 碰撞機率。
結論：
- 提議的 128 位 nonce 有更多考慮因素，使得 CTR 模式的使用更加困難。
- 對於像 GCM 大小這樣的短消息，這種方案 AES(nonce+counter) 很好。
一些注意事項：
- 對於一種產生 147.573953 艾字節的加密，64 位計數器應該足夠了。
- 長時間使用密鑰不是一個好的用法，多次使用密鑰的正確方法是正確生成隨機數。
- 隨機數的使用使我們能夠多次使用一個密鑰，並為 CPA 安全性提供機率加密概念，該概念由 Shafi Goldwasser 和 Silvio Micali 在 1984 年引入。如果你不使用，也根本沒有 CPA 安全性。
- 如果您想了解 CTR 模式的優缺點，請參閱此問題。
- 在現代密碼學中，我們更喜歡經過身份驗證的加密，如 AES-GCM 及其隨機數誤用版本 AES-GCM-SIV 和 ChaCha20-Poly1305。AES-GCM 在內部使用 CTR 模式將 AES 轉換為流密碼，類似於 ChaCha。也。
- GCM 有許多使用陷阱。如果您沒有義務使用 AES，您可以選擇 ChaCha20-Poly1305 或更好的 xChaCha20-Poly1305，它將 ChaCha20 的隨機數擴展到 192 位以安全地生成隨機隨機數。