Make CKM_AES_GCM usable.

mozilla/security/nss/lib/freebl/gcm.c

Index: mozilla/security/nss/lib/freebl/gcm.c
===================================================================
--- mozilla/security/nss/lib/freebl/gcm.c	(revision 182578)
+++ mozilla/security/nss/lib/freebl/gcm.c	(working copy)
@@ -230,7 +230,7 @@
 	PORT_SetError(SEC_ERROR_LIBRARY_FAILURE);
 	return SECFailure;
     }
-    gcm_reverse(T, X, blocksize);
+    gcm_reverse(T, tmp_buf, blocksize);

[wtc, 2013/03/26 18:24:46]

The original code passes |X| as the second argument. Note that
|X| may be incremented on line 225, which is necessary for
the mp_to_unsigned_octets call on line 228 but would be wrong
for the gcm_reverse call.

If both the AAD and plaintext are zero-length, we will
encounter this bug. For other inputs, it seems that we have
a probability of at least 1/256 to encounter this bug (if
the logical first byte of ghash->X is 0). 

[wtc, 2013/03/26 18:41:56]

If this bug in gcm_getX() only affects the zero-length AAD
and plaintext case, then I can look into bypassing the
pk11wrap layer and using the NSS softoken directly.

But I am worried that for other inputs we may still have a
1/256 probability of encountering this bug. If so, we
won't be able to use QUIC's AES GCM encrypter and decrypter
on any Linux computer (because NSS 3.15 hasn't been released
yet).

     return SECSuccess;
 }
 
@@ -575,11 +575,11 @@
 	if (rv != SECSuccess) {
 	    return SECFailure;
 	}
-	rv = gcmHash_Sync(ghash, blocksize);
-	if (rv != SECSuccess) {
-	    return SECFailure;
-	}
     }
+    rv = gcmHash_Sync(ghash, blocksize);
+    if (rv != SECSuccess) {
+	return SECFailure;
+    }

[wtc, 2013/03/26 18:24:46]

This change is not necessary (because ghash->counterBuf is
initialized to all zeros on line 568, which happens to be
the encoding of a zero length), but I think it makes the
code easier to understand.

     return SECSuccess;
 }