Comment 1:

Labels changed: added repo-main, release-none.

Comment 2:

GCM is only really defined for 96-bit nonces; other lengths are defined by converting
into a 96-bit value. See
http://csrc.nist.gov/publications/nistpubs/800-38D/SP-800-38D.pdf section 7.1.
Since other lengths are converted to 96 bits, the expected properties don't hold. For
example, a random 128-bit nonce is not as safe as one would expect. It's a little
dangerous to use IVs lengths > 96 bits because of this and it's not at all clear that
using GHASH to compress nonces is the right thing to do vs using a hash function.
Do you have some common protocol that's using large IVs with GCM?

Status changed to WorkingAsIntended.

Comment 3 by brendanmcmillion:

The output of GHASH is 128-bits.  It's not being used for compression, it's being used
to prevent an all 0 initial counter block (ICB) because if the ICB is all 0s and the
plaintext of the first block is known, then an attacker can trivially find the hash
subkey for GHASH.
If the IV is all 0s, but it's 96-bits, then you know the ICB isn't all 0s because it's
been explicitly set to have at least one 1 bit.
In many ways, you could argue that 128-bit IVs are more secure because of the larger
space to prevent repetition and the fact that an attacker doesn't actually know the
value of the ICB.
But nonetheless, the mode was standardized in a particular way and Golang's
implementation doesn't work in that way, which is generally regarded as a problem in its
own right.
Thank you for your time, btw.

Comment 4:

You're right. I didn't notice that other nonces lengths didn't have the 32 bits appended
because I've never needed it. So 128-bit nonces do, in fact, work as expected although
larger sizes don't.
Still, I'm not aware of anyone ever using larger nonces with GCM. The IETF also defines
GCM to have exactly a 96-bit nonce: https://tools.ietf.org/html/rfc5116#section-5.1
We're not painted into a corner here: support can be added without breaking the
interface, it's just a question of justification.

Comment 5 by brendanmcmillion:

To be honest, GCM implementations are hard to come by.  I only know of three:  Golang's,
OpenSSL's, and SJCL's, and Golang's implementation is the odd one out when it comes to
this:
https://github.com/openssl/openssl/blob/e0fc7961c4fbd27577fb519d9aea2dc788742715/crypto/modes/gcm128.c#L846
https://github.com/bitwiseshiftleft/sjcl/blob/master/core/gcm.js#L133
The IETF just seems to give reverence to the NIST specification that was linked earlier.
It would doubtless be a waste of time to dig through a bunch of open source projects
trying to find one case where the nonce is 128-bits and if I did would it really be
persuasive?
If blatantly not conforming to the specification and being incompatible with every other
major implementation of GCM isn't enough justification, I... don't know what would be.

Comment 6:

I think your assertion that this doesn't conform to the specification is inaccurate,
it's just that we don't implement every possibility in the spec and that is documented
in the code. We subset nearly everything aggressively in order to try and focus on doing
what's needed rather than trying to do everything.
The IETF defines AEAD_AES_128_GCM to take exactly a 96-bit nonce
(https://tools.ietf.org/html/rfc5116#section-5.1 : "N_MIN and N_MAX are both 12 octets")
and TLS thus uses a 96-bit nonce.
I'm not against supporting other nonce sizes should it be needed, but your motivation
appears to be that we should support it simply because it has been defined and I don't
agree with that.