The NIST has a "SP 800-38D: Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC". This guideline is a base for AES-GCM from definition to security considerations. ( all bolds are mine)
In section 8.2.1 Deterministic Construction IV
In the deterministic construction, the IV is the concatenation of two fields, called the fixed field and the invocation field. The fixed field shall identify the device, or, more generally, the context for the instance of the authenticated encryption function. The invocation field shall identify the sets of inputs to the authenticated encryption function in that particular device.
and later in the same section
The invocation field typically is either 1) an integer counter or 2) a linear feedback shift register that is driven by a primitive polynomial to ensure a maximal cycle length. In either case, the invocation field increments upon each invocation of the authenticated encryption function.
The distinction of a counter and Linear Feedback Shift Register (LFSR) is clear. A counter can be simply implemented in the CPU registers in construct an LFSR that requires a primitive polynomial and extra code. Selecting/finding a primitive polynomial is not hard today. As listed in this SO answer there is a report from HP list the binary primitive polynomial of low-degree. One can also use Maple, Mathematica, and SageMath to find one.
If everything works correctly, the counter and LFSR can produce unique IV's that are crucial for the security of the AES-GCM. Any (IV,Key) pair use can remove the confidentiality and can cause forgery.
There is one problem that I'm aware of; during the system failures, the last incremented/advanced counter/LFSR value can be lost. If the administrators continue from the last known values this can result in (key,IV) pair reuse. To mitigate either exchange a new key or use random in some part of the IV.
In the comment of the answer of What are the rules for using AES-GCM correctly?
Maarten Bodewes said
Sorry, but I don't understand why you'd need a LFSR specifically rather than a generic DRBG.
and also
Gilles 'SO- stop being evil' said
This is good advice except for the LFSR. A non-cryptographic RNG has no place in crypto code.
and
I wonder why they suggest an LFSR. It's a pity that they don't give a rationale.
So the questions for the AES-GCM are;
What is the rationale of the NIST to suggest counter and LFSR for IV.
Why using an LFSR is not good advice?
In section 8.2.2 RGB-based construction talk about RGB(Random Bit Generator) in two ways
- an output string of r(i) bits from an approved RBG with a sufficient security strength, or
- the result of applying the r(i)–bit incrementing function to the random field of the preceding IV for the given key
Is there any advantage of RGB against counter/LFSR?