[denimnerd42]

The problem with a random nonce is that most implementations also use a nonce of 12 bytes which under some use cases might not be enough before you repeat a nonce. So to remedy this they suggest using a counter but this could be hard to implement.

When I use AES-GCM I just use a bigger nonce and use a random one.

Last time I used AES-GCM I had a really hard time getting the person writing the other end to not re-use nonces.

[kvemkon]

> nonce and use a random one

Recently discussed: "Galois/Counter Mode and random nonces" (28.05.2024) https://news.ycombinator.com/item?id=40497525

[imurray]

> When I use AES-GCM I just use a bigger nonce and use a random one.

I don't think nonces bigger than 12 bytes will help. My quick reading of the AES-GCM spec is that when using a nonce that's not 96 bits (12 bytes), it is hashed to 96 bits. So either the nonce (called iv in the spec) is carefully constructed from a counter and set to exactly 96 bits, or the number of invocations is limited. The spec still restricts use of a key to 2^32 total uses for random nonces of any bigger length (resulting in a re-use probability of about 1e-10):

https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpubli...

[kbolino]

Nonces (called IVs in the spec) of any length other than 96 bits are fed into GHASH before use, which has 128 bits of output. This means that IVs can't contribute more than 128 bits of entropy but they may be able to contribute up to that many; it's not clear to me what effect GHASH has on the entropy of the IV though.

[imurray]

You're right, GHASH has 128 bits output. I'd wrongly assumed it was 96 from my quick reading of the conclusion on p29:

> unless an implementation only uses 96-bit IVs that are generated by the deterministic construction: The total number of invocations of the authenticated encryption function shall not exceed 2^32, including all IV lengths...

Which would be the conclusion if the hash was always reduced to 96 bits. What it actually goes on to say though is:

> For the RBG-based construction of IVs, the above requirement, in conjunction with the requirement that r(i)≥96, is sufficient to ensure the uniqueness requirement in Sec. 8

So, it's a bound. If there are at least 96 random bits, it should all be ok. But it strangely leaves open the possibility, without saying either way, that a longer iv, with r(i)>96 random bits might allow generating more iv's. As you point out, it will depend on the properties of GHASH (and potentially on how the result is used downstream from there). At this point I don't know, but the spec says:

> For IVs, it is recommended that implementations restrict support to the length of 96 bits, to promote interoperability, efficiency, and simplicity of design.

So personally, not being an expert, I'd follow the advice and use 96 bit iv's. And if using random iv's, re-key before using the key a billion times. I'd certainly want a reference to a careful analysis before assuming that I could ever use an AES-GCM key with longer random iv's more than that.

[frereit]

> But it strangely leaves open the possibility, without saying either way, that a longer iv, with r(i)>96 random bits might allow generating more iv's. As you point out, it will depend on the properties of GHASH (and potentially on how the result is used downstream from there).

There is some details on the "GHASH as initial counter value" which seem to suggest that for larger nonces, the total number of messages shouldn't exceed 2^44.5 here: https://neilmadden.blog/2024/05/23/galois-counter-mode-and-r...

[kbolino]

Yeah, interoperability basically dictates 96-bit nonces. I'd say GCM is hard to use correctly for any situation where you have an indefinite amount of data to encrypt and you can't do deterministic nonce generation and you can't rekey easily.