2 Answers
2

You could, however the one part that doesn't translate in an obvious manner is the Galois field representation; you would need to pick a field representation for $GF(2^{256})$ and $GF(2^{512})$, because those have not be predefined for those sizes.

Here's the issue; GCM does field multiplications internally; that is, it takes two $N$-bit vectors (where $N$ is the block size of the cipher), interprets them as field elements in $GF(2^N)$, multiplies those two elements, and those maps that result back into an $N$-bit vector.

Why is this a problem? Well, exactly what is the mapping between bit vectors and field elements? It turns out that there are a lot of plausible mappings; from a security standpoint, it doesn't matter (the GCM proofs all work regardless of the representation); however it matters a great deal for interoperability.

For the fields $GF(2^{128})$ and $GF(2^{64})$, that's all defined by the standard; in both cases, we use a polynomial representation, using the irreducible polynomial $x^{128}+x^7+x^2+x+1$ for $GF(2^{128})$ and the irreducible polynomial $x^{64}+x^4+x^3+x+1$ for $GF(2^{64})$ (and the bit order is backwards from what you'd expect; so the multiplicative identity (1) is represented by the bit pattern $80$ $00$ $00$ $00$ .. $00$).

All is well and good for the two block sizes specified by NIST, but you are asking about 256 and 512 bit block sizes; even if we stay with a polynomial representation (and the same backwards bit-ordering), you'd still need to select irreducible polynomials of the correct degree.

Looking through the web, I see a claim that the polynomials $x^{256}+x^{10}+x^5+x^2+1$ and $x^{512}+x^8+x^5+x^2+1$ are irreducible; I cannot confirm that (and the web site has a cavaet as well); however if so, they would be viable options. This paper also lists some primitive (and hence irreducible) polynomials, however they aren't minimal (which would be the obvious one to use)

$\begingroup$Why would you have to choose a larger field? AFAIK GCM only uses the underlying cipher as stream cipher, so the block size shouldn't matter at all (if it is at least the field size, for smaller blocks a bit of special handling might be required)$\endgroup$
– CodesInChaosFeb 17 '14 at 9:41

1

$\begingroup$@CodesInChaos: hmmm, good point. GCM, as specified, matches the block size with the field size. If we break that assumption, and: use the first 128 bits of the encryption of 0 as your H; and do some reasonable splitting of the keystream to encrypt the payload and the tag (I can think of two reasonable alternatives), well, one gets something that is distinctly GCM-ish, and I still believe the security proofs still apply.$\endgroup$
– ponchoFeb 17 '14 at 14:23

$\begingroup$@CodesInChaos The question becomes: what use is a larger block size and if we need a larger block size for security, shouldn't we also increase the security of the authentication tag?$\endgroup$
– Maarten Bodewes♦Feb 17 '14 at 17:51

1

$\begingroup$@owlstead Security and block size are only loosely coupled. The main advantage of larger block sizes is that you get larger IVs, so you can safely use a random IV. I'd guess the main reason for using larger block sizes is that your cipher (say Threefish) happens to have larger blocks.$\endgroup$
– CodesInChaosFeb 17 '14 at 18:30

As far as I can see you would have (at least) to define a wider polynomial for the multiplication over the GF(256) or GF(512) respectively (See point 2.5 Multiplication). It is unclear if you can do that without touching the overall security of the algorithm.

I would not rely on the security of these modified algorithms without extensive research of the impact on the security.