Re: [Crypto-panel] Review of AES-GCM-SIV

Please find my review below. It's a nice piece of work and overall in quite
good shape.

After looking at the other reviews: I do not quite understand Tibor's
comment on the bit-length vs. byte-length, given that the draft states that
the scheme takes "arbitrary-length plaintext & additional data
byte-strings" -- and for me the term "byte-strings" means that the
byte-length of the strings is an integer. However, since this lead to
confusion, it may make sense to state this more explicitly.

Best,
Björn

============================
Summary: Almost ready

Major issues: none

Minor issues:

I found the description of the encryption method comprehensible but a bit
too informal. Maybe a pseudo-code description may be easier to understand?

In that description, I stumbled particularly over the “_length block_” -
why the underscores? Also, I think it would make sense to clarify that the
32-bit counter value will overflow (and that this is intended).

One aspect that read a bit arbitrary to me was the domain separation for
AES by setting the first bit of the last byte to 1/0, and in particular
that seemed a bit wasteful since it is evaluated only once with the bit set
to 0. Wouldn't it be simpler (and possibly even with better security, but
at the cost of limiting the length to 2^32 - 1 blocks) to not fiddle with
the bits but just use the first counter-block to compute the tag? Note that
this would certainly require re-doing some part of the security analysis,
and the gains seem moderate, so I’m fine with this comment being discarded.
(Just wanted to make sure it is discarded consciously.)

On Thu, Jun 15, 2017 at 4:38 PM, Paterson, Kenny <Kenny.Paterson@rhul.ac.uk>
wrote:

> Dear CFRG panel members,
>
> Any volunteers from the panel to perform a review of:
>
> https://tools.ietf.org/html/draft-irtf-cfrg-gcmsiv-04
>
>
> I'd like to move it towards last call, and having a couple of reviews from
> you fine people would help give us the confidence to do so.
>
> The draft might be best read in conjunction with the technical paper:
>
> https://eprint.iacr.org/2017/168
>
>
> though of course it needs to stand alone as an RFC.
>
> Let me know.
>
> Cheers,
>
> Kenny
>
> _______________________________________________
> Crypto-panel mailing list
> Crypto-panel@irtf.org
> https://www.irtf.org/mailman/listinfo/crypto-panel
>