> 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?
As ctx->mres and ctx->ares can't be both non-zero, it's sufficient to check for (ctx->mres || ctx->ares). Zeroing ctx->ares is not necessary, because second call to CRYPTO_gcm128_finish would be [cryptographically] catastrophic anyway. Therefore http://cvs.openssl.org/chngview?cn=22745. > 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. > ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
