Runtime: AesGcm NonceSize Restriction

[dominicle8]

Currently, the AesGcm class only supports encryption and decryption with a nonce size of 12 bytes:
https://github.com/dotnet/corefx/blob/6d86975666ecd2e2b4f5ab808dcfeff94fd18789/src/System.Security.Cryptography.Algorithms/src/System/Security/Cryptography/AesGcm.cs#L11

I understand that section 5.2.1.1 of the NIST Special Publication 800-38D suggests that a 12 byte nonce is used, stating "For IVs, it is recommended that implementations restrict support to the length of 96 bits, to promote interoperability, efficiency, and simplicity of design." Were there other factors in placing the restriction on the nonce byte size? And, are there plans to expand support for more nonce sizes?

[vcsjones]

I think one barrier to additional nonce sizes is that Windows' CNG implementation does not support a nonce size other than 96-bits. So 12 octets is the only value that will work on all platforms.

Now that Windows' GCM default implementation is open source (:tada:), we can double check that, and indeed it only allows a 96-bit nonce:

https://github.com/microsoft/SymCrypt/blob/d74a6ec659043e40e74106ee33b373be38c20508/lib/gcm.c#L34-L40

/cc @bartonjs @krwq

[vcsjones]

Out of curiosity, do you have a use case for a nonce size other than 96-bits? I have never seen AES-GCM practically used with a different nonce size. Personally, I don't see much value in a nonce size other than 96-bits. Either way you end up with a 128-bit pre-counter, but using 96-bit nonce avoids a call to GHASH.

[dominicle8]

I agree, I don't see much value in not using a 96-bit nonce, but my use case would be for backwards compatibility after porting a .NET framework application (where a nonce that wasn't 96-bits was used) to .NET core to be run on a linux machine. Moreover, in my situation, it may not be feasible to decrypt all ciphertexts and re-encrypt them with a 96-bit nonce. Considering openssl and openssl fips does not place the same nonce size restriction, is the intention to limit the functionality in the corefx's AesGcm by enforcing a 12-byte nonce or are there plans to expand support for difference nonce sizes in Windows' CNG implementation and remove this restriction altogether? Or plans to remove this restriction without expanding support in Windows' CNG?

[vcsjones]

but my use case would be for backwards compatibility after porting a .NET framework application

The .NET Framework doesn't support AES-GCM at all let alone non-96-bit nonces, so whatever you are using for .NET Framework, I assume a 3rd party library, with AES-GCM today I suppose you could continue to use in .NET Core.

[dominicle8]

Unfortunately, the FIPS compliant version of the library we are currently using for AES-GCM does not support .NET core. We were hoping to use the Openssl fips module through System.Security.Cryptography.

[bartonjs]

OS specific differences are harder to test, and harder for users to depend on. I think it would take a major standard using GCM with something other than a 96-bit nonce for us to move off of the current position of consistency.

Is the intention to limit the functionality in the corefx's AesGcm by enforcing a 12-byte nonce

Until we have a strong need to do otherwise. GCM is one of cryptography's finest foot-guns and nonce sizes other than 96 bits just make the trigger a bit more sensitive.

are there plans to expand support for difference nonce sizes in Windows' CNG implementation and remove this restriction altogether?

I likewise expect that Windows would only move their implementation for a major standard demanding it; like a future IEEE 802.11 or a future TLS.

[krwq]

If underlying implementation has a way to allow smaller nonces and there is a legitimate use case we might consider adding a flag for legacy code which will be off by default but that would be considered only after API proposal & review and strong use case.