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

[Tony Arcieri <[e-mail]>]

On Tue, Jan 1, 2019 at 3:34 AM Björn Edström <[e-mail]> wrote:

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

I've written a toy Rust implementation of POLYVAL along these lines with an
IUF API (which is untested and almost certainly broken):

https://github.com/miscreant/miscreant.rs/blob/047ae8b3fd68d62eeb1e8510110439ba24473df3/src/polyval.rs

I attempted to implement an idea which is described (although I'm unsure if
it's actually "recommended") in the RFC: using POLYVAL to implement GHASH.

If we could get this to work, I think a neat thing to attempt would be
implementing both AES-GCM and AES-GCM-SIV using a shared "polyval" library
(a.k.a. crate in Rust terminology).

We've also discussed creating a Rust trait (more or less an interface) for
universal hash functions, which could have a common IUF API that an
instantiation of POLYVAL (or GHASH in terms of polyval) could implement.

-- 
Tony Arcieri