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

[Adam Langley <[e-mail]>]

On Mon, Sep 18, 2017 at 10:51 AM, Andy Polyakov <[e-mail]> wrote:
>
> 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?

Anyone who has implemented GHASH has had to wrestle with the
specification's handling of bit ordering, it's confusing beyond
questions of little- vs big-endian.

But it's also the case that little-endian machines now dominate. It's
nice that some big cores can largely hide the cost of doing the byte
swap, but hiding work is not the same as avoiding it (as your Skylake
numbers show) and smaller cores may not be able to do the
out-of-order, superscalar magic needed. POLYVAL is GHASH done right
for the world as we find it.

As for diversity: that's a cost. Although it's smaller here than in
many cases. Where the diversity costs really bubble up is when they
spread up the stack and we have, say, RSA-with-SHAKE128 to test and
validate everywhere. I think the diversity cost of AES-GCM-SIV is
concentrated in its very existence (i.e. that it's not AES-GCM). For
cases where AES-GCM-SIV isn't being written as a stitched asm blob
(where the full implementation cost of either POLYVAL or GHASH is be
paid anyway), BoringSSL uses the mapping to GHASH to avoid another
implementation, as specified in the draft.


Cheers

AGL

--
Adam Langley [e-mail] https://www.imperialviolet.org