> I noticed that the `H` member of `gcm128_context` seems to be > unnecessary for builds that aren't using the 1-bit GCM math. Since > this member is large (128-bits) and some applications may have lots of > GCM contexts relative to the amount of memory they have, I think it > would be great to only put the `H` member into the structure when the > 1-bit math is used.
Not true. It is actually used in s390x assembly module. And I mean both H and Htable. This is because hardware-assisted single multiplication is not faster than pure software. In practical terms it means that Htable is used when you need to perform single multiplication, and H is used when you process multiple input blocks in one go. > I tried to write a patch to do this myself, but I got stuck, because > the assembly language code does pointer math assuming that the `H` > member (which it doesn't use, AFAICT) is there. And, I can't quite > understand the assembly language code well enough to adjust all the > offsets to make the code work with `H` removed. > > Could somebody adjust who understand the assembly code (probably Andy) > modify it to use symbolic names for the offsets that are used to > access Xi, H, Htable? If so, then I can write the patch to > conditionally exclude `H` on platforms that don't need it after > `CRYPTO_gcm128_init` finishes executing. In cases other than s390x it's likely to be optimization thing. I mean as you tend to use all the registers you are likely to find it beneficial to discard Xi and use Htable to address both. But going the line of taking into consideration all corner cases is a stretch and should be weighed against 16 out of ~380[!] bytes waste. I'd say it's not worth it. One can argue that "the most popular embedded three-letter platform" deserves this 4% space optimization [by being so popular], but then question would be if OpenSSL can actually execute in such constrained environment where 4% per GCM context (i.e. something that itself is percentage of something else) makes a difference. Aren't we likely to be talking about ripping out single component and using in the said environment? But then question is why this specific case would have to complicate maintenance for OpenSSL as whole? In other words I'd vote for saying no to omitting H. However, I can tell that assembly module for "the most popular embedded three-letter platform" does *not* depend on relative position of Xi, H and Htable. One can *probably* discuss that it would be appropriate to *facilitate* omission of H in context *other than* OpenSSL by avoiding H during most of the setup procedure. See attached patch for example. But do note that I'm not saying that it works or suggesting to include it right away, I only want to show what *might* be matter of discussion. > Also, I wonder how important it is to keep the 1-bit math code? Look at it as insurance. The moment they come and say table-driven approach is no-go, we have 1-bit code to switch to. -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
