Hi, > I've compiled a recent SNAP of OpenSSL 1.0.1 (from 18/12). I am > pretty sure that the assembly language code generated for the ghash > function (in ghash-x86.s) is incorrect. > > The gcm_init_4bit() function generates a 16-entry table of 128-bit > values, to be used as a multiplication table. The first value is > always zero, while the others usually aren't. > > The supposedly equivalent gcm_init_clmul() function does not touch > indexes 2-16 of the table, and pushes two usually non-zero entries > into the first two entries of the table. > > Notice how %edx holds a pointer to the Htable, while %eax holds a > pointer to H. The final two lines of the function put a value in the > first ((%edx)) and second (16(%edx)) positions of the table. Clearly, > this is wrong.
It *would* have been wrong *if* assumption that gcm_init_clmul() and gcm_init_4bit() are equivalent was correct. But these two functions are *not* equivalent, and gcm_init_4bit's output can not be used by gcm_[gmult|ghash]_clmul and vice versa. And it, "cross usage", is never case [in OpenSSL], because if CRYPTO_gcm128_init sets up pre-computed table with gcm_init_4bit, it even retains pointers to *matching* gcm_[gmult|ghash]_4bit_[mmx|x86]. Same naturally applies to *_clmul counterparts. And yes, *_clmul subroutines utilize only 2 out of 16 slots of Htable, it's conscious choice. ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [email protected] Automated List Manager [email protected]
