NIST 關於 SP 800-38D 上確定性 IV 結構的計數器/LFSR 建議背後的基本原理
NIST 有“ SP 800-38D：分組密碼操作模式建議：伽羅瓦/計數器模式 (GCM) 和 GMAC ”。該指南是 AES-GCM 從定義到安全考慮的基礎。（所有粗體都是我的）
在第 8.2.1 節確定性構造 IV
在確定性構造中，IV 是兩個欄位的串聯，稱為固定欄位和呼叫欄位。固定欄位應標識設備，或更一般地，標識已驗證加密功能實例的上下文。呼叫欄位應標識該特定設備中已驗證加密功能的輸入集。
稍後在同一部分
呼叫欄位通常是 1)整數計數器或 2)線性回饋移位寄存器，由原始多項式驅動以確保最大周期長度。在任何一種情況下，呼叫欄位都會在每次呼叫已驗證的加密函式時遞增。
計數器和線性回饋移位寄存器 (LFSR) 的區別很明顯。計數器可以簡單地在 CPU 寄存器中實現，以建構需要原始多項式和額外程式碼的 LFSR。今天選擇/找到一個原始多項式並不難。如this SO answer中所列， HP有一份報告列出了低度的二進制原始多項式。也可以使用 Maple、Mathematica 和 SageMath 來查找。
如果一切正常，計數器和 LFSR 可以生成對 AES-GCM 的安全性至關重要的唯一 IV。任何（IV，Key）對的使用都可以消除機密性並可能導致偽造。
我知道一個問題；在系統故障期間，最後一個遞增/高級計數器/LFSR 值可能會失去。如果管理員從最後一個已知值繼續，這可能導致 (key,IV) 對重用。為了減輕在 IV 的某些部分中交換新密鑰或使用隨機的風險。
抱歉，但我不明白為什麼您需要專門的 LFSR 而不是通用的 DRBG。
並且
這是一個很好的建議，除了 LFSR。非加密 RNG 在加密程式碼中沒有位置。
和
我想知道他們為什麼建議使用 LFSR。可惜他們沒有給出理由。
所以 AES-GCM 的問題是：
NIST 建議 IV 使用 counter 和 LFSR 的理由是什麼？
為什麼使用 LFSR 不是一個好建議？
在第 8.2.2 節基於 RGB 的構造中，從兩個方面談論 RGB(Random Bit Generator)
來自具有足夠安全強度的已批准 RBG 的 r(i) 位輸出字元串，或
將 r(i)–bit 遞增函式應用於給定密鑰的前一個 IV 的隨機欄位的結果RGB 對計數器/LFSR 有什麼優勢嗎？
我不知道這是否是 NIST 的動機，但我發現一篇論文在某些應用中對 LFSR 計數器有一個論據：
- Mukhopadhyay、Sourav 和 Palash Sarkar。2006.“LFSR 在密碼算法中用於並行序列生成的應用”。密碼學 ePrint 檔案：報告 2006/042。
**抽象的。**我們考慮在硬體中有效生成序列以用於某些密碼算法的問題。執行此操作的正常方法是使用計數器。我們展示了由線性回饋移位寄存器 (LFSR) 生成的序列可以定制以適應適當的算法。對於硬體實現，這減少了時間和晶片面積。因此，我們能夠對電子前沿基金會於 1998 年建構的 DES Cracker 的設計提出改進建議；提供一種有效的策略來生成時間記憶權衡攻擊的起點；並且提出了分組密碼的計數器操作模式的變體的改進的並行硬體實現。
正如我在對該問題的評論之一中提到的那樣，NIST SP 800-38a（“塊密碼操作模式建議”，2001 版）也提到 LFSR 作為計數器塊的允許遞增函式的範例（第 18 頁） ，因此該技術早於 GCM 和本文。
RFC 3686（“使用具有 IPsec 封裝安全負載 (ESP) 的高級加密標準 (AES) 計數器模式”，2004 年 1 月）也允許使用 LFSR 計數器塊。它說 LFSR 是一種常見的 IV 生成方法（第 5 頁），並且間接地吸引了與 Mukhopadhyay 和 Sarkar 相似的動機，因為它們允許它們：
$$ p. 14 $$允許加法器、LFSR 和任何其他滿足加密器時間預算的技術，只要該技術為每個數據包產生唯一值。加法器實現起來簡單直接，但由於進位，它們不會在恆定時間內執行。LFSR 提供了一種在恆定時間內執行的替代方案。
說 LFSR 在恆定時間內執行確實違反了我們軟體人員的直覺，他們傾向於更普遍地認為加法是“簡單的”但 LFSR 是“複雜的”。