Hi,

I apologize for chiming in so late, but I wasn't aware of this endeavour
till very recently. The question I find myself struggling with is that I
can't find introduction of new primitives justified, at least not in
this context. I did my best sieving through
https://mailarchive.ietf.org/arch/search/?q=gcmsiv) to locate relevant
prior comments, so even with those in mind. One of arguments was that
POLYVAL gets bit order right in comparison to GHASH. Well, comparing the
two is actually boils down to one question: what is it you choose to
bit-flip, input or polynomial? [Do note "bit-flip", not "byte-flip".]
What I'm trying to say is that we have to recognize that POLYVAL is
simply formulated in terms of GHASH polynomial in reverse bit order. On
the other hand on more practical level, i.e. from software
implementation viewpoint, answer to the question is self-obvious, it's
more efficient to bit-flip single polynomial than each fragment of the
input. This last thing effectively means that sensible GHASH
implementation would actually use reverse-bit polynomial (and at least
OpenSSL implementations all do). This in turn means that the only
essential difference between GHASH and POLYVAL is byte order. Now, it
was argued that little-endian byte order gives performance edge [on
platform of popular choice]. But relevant question in the context is if
the edge actually justifies introduction of new algorithm. It was
asserted that it provides 20% improvement and it was attributed to the
fact that PCLMULQDQ-based GHASH implementations use vector byte swap
instructions, *one* per block. But we have to recognize that said
improvement coefficient is actually specific to Skylake. For example on
Haswell we'll observe ... 0% improvement, on Broadwell - 6%, on Ryzen -
3%. Let's even have a look at absolute cycles per processed byte values
for GHASH:

Haswell   0.41
Broadwell 0.29
Skylake   0.36

Do note that effectively we observe regression on Skylake, also note
that it's ~20%. I mean if Skylake inherited Broadwell qualities, GHASH
would have performed ~20% better. With all the numbers in mind it's only
natural to conclude that vector byte swap "costs" unproportionally much
specifically on Skylake [and in GHASH], and it's rather anomaly than
rule. And it's not unlikely to be addressed in next processor
generation. At least other alike cases were, just look at improvement
from Haswell to Broadwell above. And if not, maybe it would still be
more appropriate to demand that Intel fixes this in next-next
generation, instead of introducing new algorithm. Because latter
approach is not really sustainable. I mean how many algorithms would we
have to implement and support if they were introduced on per
specific-processor-pipeline-anomaly basis? Besides, even 20% improvement
has to be considered in overall context, not by itself. I mean if the
only difference between two otherwise equivalent proposals was POLYVAL
vs. GHASH, then improvement for *whole* operation would be ~6% [on
Skylake, and none to negligible on others]. Or in other words this
proposal *could* just as well be formulated with GHASH instead of
POLYVAL, there is no *compelling* reason to introduce another algorithm.

And same can be said about suggested CTR tweak. I.e. suggested mode
*could* just as well be formulated with standard CTR. Even more so, as
there is no apparent difference in performance [on platform of popular
choice].

Well, it's not like I actually reject the sentiment to favour
little-endian platform[s], question rather is if *mode* specification is
right place for it. Protocols are about *communication* and there are
more factors in play, most notably using already available primitives
would facilitate adoption. And if little-endian-centric primitives are
deemed desirable, wouldn't it be more appropriate to define them
separately to promote modularity and re-usability?

Cheers.