[openssl-dev] Removing gcm128_context->H for non-1-bit builds

[Andy Polyakov]

> 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.