P1619.1: Incompatibility of GHASH function between GCM spec and SP 800-38D
Hi Dr.
Dworkin,
There is an issue
that just came to light about the GCM mode, concerning compatibility between the
proposal from McGrew and Viega, and the NIST draft SP 800-38D. It looks
like the GHASH functions are incompatible when used to process an IV that is not
96-bits long. The original GCM proposal includes the IV length within the
GHASH calculation, and the new NIST proposal does not include this
length.
This difference
invalidates the GCM test vectors 10 and 11 within P1619.1-D7, and also
invalidates any existing GCM implementation that supports an IV that is not
96-bits long. Was this the intent of SP 800-38D, or should we expect the
final NIST standard to match the GCM proposal?
Here are more
details:
In the GCM proposal
by McGrew and Viega, the variable Y0 is computed using GHASH(H, {}, IV) (see
equation (1), page 5). Within equation (2), the bit-length of the IV is
included at the end of the computation.
In Draft SP 800-38D,
the GHASH function specified in 7.4 does not include a length field. This
is okay for authenticating the data because step 5 of section 8.1 then includes
"len(A) || len(C)" at the end. However, the J0 computation does
not include the length.
I believe that it
would be possible to make SP 800-38D match the GCM proposal by making the
following change to SP 800-38D, section 8.1 "Authenticated Encryption"
(changes in bold):
Steps:
...
2. Define a block,
J0, as follows:
...
b. If len(IV)
<> 96, then
J0 = GHASHh(IV
|| 0^s || 0^64 ||
[len(IV)]64)
where '^' is
the exponentiation operator (which in this case is actually a duplication
operator).
Thanks!
Matt Ball
Embedded
Software Engineer
Quantum Corporation
4001 Discovery Drive, Suite 1100
Boulder, CO 80303
(720)
406-5766