[openssl.org #2859] Possible bug in AES GCM mode

[John Foley via RT]

This problem occurs in the FIPS 2.0 and 2.0.1 Object Modules.   The 
conditions for the test are:

Platform:  Linux 32-bit
AAD length:  greater than 16 bytes and not evenly divisible by 16 (e.g. 
20 bytes of AAD)
Cipher text length: 0

Under these conditions, the remaining AAD bytes beyond the last 16 byte 
block are never hashed.  This results in a TAG mismatch when finalizing 
the decrypt operation.  The problem can be easily reproduced by running 
the following command using the attached test vector file:

test/fips_gcmtest -decrypt gcm_decrypt_vect.req vector.rsp

The test case in this vector should result in a matching tag.

The attached patch is a potential fix.  The solution is to process the 
remainder AAD when CRYPTO_gcm128_finish() is invoked.  Please confirm 
that this is a bug and comment on the patch.  Specifically, will this 
patch work on all platforms?  Thank you.

Also, the OpenSSL test vectors for AES GCM mode only used AAD lengths 
that were divisible by 16, which explains why this problem was not 
identified during FIPS validation.

Index: crypto/modes/gcm128.c
===
--- crypto/modes/gcm128.c	(revision 713)
+++ crypto/modes/gcm128.c	(working copy)
@@ -1396,6 +1396,15 @@
 #ifdef GCM_FUNCREF_4BIT
 	void (*gcm_gmult_p)(u64 Xi[2],const u128 Htable[16])	= ctx-gmult;
 #endif
+	/*
+	 * Check if there is any residual AAD that needs to
+	 * be hashed.  This may occur if the amount of AAD
+	 * is not evenly divisible by 16 bytes 
+	 */
+	if (ctx-ares) {
+		GCM_MUL(ctx,Xi);
+		ctx-ares = 0;
+	}
 
 	if (ctx-mres)
 		GCM_MUL(ctx,Xi);
# CAVS 12.2
# GCM Decrypt with keysize 192 test information
# Generated on Mon Jul 30 13:55:03 2012

[Keylen = 192]
[IVlen = 96]
[PTlen = 0]
[AADlen = 160]
[Taglen = 128]

Count = 1
Key = cb9c9ba95ba34917db831e2f8438b5c9e702a1dfe2aa5451
IV = 1e19de9f8ec80fd940d07e4f
CT = 
AAD = 01d783d290c62d6c46d6adda205057e327029586
Tag = cade2680b5bb72d7a9ef8dc2388353f1

inline: foleyj.vcf

Re: [openssl.org #2859] Possible bug in AES GCM mode

[John Foley]

Thanks for confirming and providing the work-around.

Do you see any problems with the proposed patch, which could still be 
applied to the 1.0.1 trunk to avoid the work-around for non-FIPS users?




On 08/03/2012 09:10 AM, Stephen Henson via RT wrote:

[fol...@cisco.com - Fri Aug 03 10:51:37 2012]:

Under these conditions, the remaining AAD bytes beyond the last 16 byte
block are never hashed.  This results in a TAG mismatch when finalizing
the decrypt operation.  The problem can be easily reproduced by running
the following command using the attached test vector file:


I can confirm the results. There is an alternative which doesn't involve
any changes to the validated algorithm code though.

If you make a call to EVP_Cipher with non-NULL input and output buffers
and the length set to zero this case should then be handled correctly. I
made a small modification to fips_gcmtest.c to confirm this.

Steve.
attachment: foleyj.vcf

Re: [openssl.org #2859] Possible bug in AES GCM mode

[John Foley via RT]

Thanks for confirming and providing the work-around.

Do you see any problems with the proposed patch, which could still be 
applied to the 1.0.1 trunk to avoid the work-around for non-FIPS users?



On 08/03/2012 09:10 AM, Stephen Henson via RT wrote:
 [fol...@cisco.com - Fri Aug 03 10:51:37 2012]:

 Under these conditions, the remaining AAD bytes beyond the last 16 byte
 block are never hashed.  This results in a TAG mismatch when finalizing
 the decrypt operation.  The problem can be easily reproduced by running
 the following command using the attached test vector file:

 I can confirm the results. There is an alternative which doesn't involve
 any changes to the validated algorithm code though.

 If you make a call to EVP_Cipher with non-NULL input and output buffers
 and the length set to zero this case should then be handled correctly. I
 made a small modification to fips_gcmtest.c to confirm this.

 Steve.

inline: foleyj.vcf

Re: ppc32_asm for BSD targets

[Peter Waltenberg]

 Not a definitive answer, but I know we (IBM) never tested the PPC asm on BSD. It's possible that because no one had a PPC machine running BSD to test the asm paths they were left disabled. There may be other reasons, but make tests should at least show any gross problems.The only subtle problem I can think of that might be there in recent code is use of 64 bit registers in 32 bit code, if the kernel doesn't preserve the upper halves of registers you can get clobbered during signal handling. I don't know enough about current BSD to know if that's a problem or not.Peter-owner-openssl-...@openssl.org wrote: -To: openssl-dev openssl-dev@openssl.orgFrom: Kevin Fowler Sent by: owner-openssl-...@openssl.orgDate: 08/04/2012 01:04AMSubject: ppc32_asm for BSD targetsFor the BSD-generic32 target, which gets used for *bsd on ppc cpu, Configure script uses ${no_asm}. Other OS's (linux, darwin, AIX) on ppc cpu use ${ppc32_asm}.Are the ppc asm routines not valid for *bsd OS? If so, what about BSD invalidates them?
Thanks,Kevin
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org