[Cfrg] AES-GCM-SIV: Expository interpretation of POLYVAL as an IUF construction

[Björn Edström <[e-mail]>]

This is maybe obvious, stupid, or both, but I felt like sharing:

In the internet draft for AES-GCM-SIV, POLYVAL is explained as a function
POLYVAL(H, X_1. X_2...) and the AES-GCM-SIV construction is shown as a
special implementation of AES-CTR using this POLYVAL function in the
encrypt() and decrypt() step. This is tight, performant, and clear.

As an alternative way to explain the AES-GCM-SIV construction, consider
instead trying to implement it as much as possible as composition of
primitives. That is:

* Given a decently standard AES-CTR implementation
* ...And interpreting POLYVAL as an Init/Update/Finalize hash construction
- a primitive in it's own right

Then the entirety of AES-GCM-SIV can be implemented as a few lines of glue
code. Have a look:
https://github.com/bjornedstrom/aes-gcm-siv-py/blob/master/reference.py

Semi-philosophical point: This approach is only reasonable if you "lift"
POLYVAL into a valuable and generic primitive on it's own, that is not just
a detail of AES-GCM-SIV but something that is useful in it's own. For
cognitive load reasons, then POLYVAL can be treated as a black box similar
to hash functions in general, instead of something that is "part of"
AES-GCM-SIV. </weird crackpot comment>

Cheers
Bjorn