Re: [Cfrg] RG Last Call on draft-irtf-cfrg-gcmsiv-06

[Andy Polyakov <[e-mail]>]

>>>>> do we all agree that "consistency" is sufficient by its own?
>>
>> To me, a clean and consistent specification has value.
> 
> I don't deny its value, question was it is sufficient [to justify
> additional implementation/diversity costs].

It's obvious that more natural bit order in POLYVAL was not the goal by
itself. Performance on par with GCM also was. And not just any GCM
performance, but one assisted by AES-NI and PCLMULQDQ instructions or
their equivalents. Next thing to understand is that referred GCM
performance is achieved by optimizing for specific cases, CTR and GHASH,
and in x86_64 case even stitched CTR-GHASH. And keyword is "specific
cases". Draft in question asserts that suggested mode decrypt
performance is virtually equivalent to GCM, but fails to emphasize that
this holds true only provided that one has devoted equivalent effort
into optimizing code for specific cases of modified CTR and POLYVAL.
Because if one doesn't do that and takes "easy way out" by exploiting
byte order equivalence with GHASH and modified CTR relying on
single-block encrypt, performance impact would be devastating, up to
several *times*. On the other hand if mode was specified using GHASH and
standard CTR, as already discussed, difference would be none to
negligible [in non-anomalous cases].

>>>>> those who choose "easy way out". 
>>>>> because they have dedicated GHASH hardware. 
>> As Adam had mentioned, adding AES-GCM-SIV (to gain misuse resistance)
>> has its cost anyway,
> 
> Yes, and assertion is that it could have been *lower* if it was
> formulated with GHASH and standard CTR.

Because it would be limited to ordering calls to existing GHASH and CTR.

Cheers.