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

["Paterson, Kenny" <[e-mail]>]

Thanks Bjoern for this revision.

On 04/07/2017 16:01, "Bjoern Tackmann" <[e-mail]> wrote:

>Thanks, Kenny, and please find my updated report below.
>
>
>=========================
>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 explicitly
>clarify that the 32-bit counter value for the CTR part is explicitly
>allowed to overflow.
>
>
>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.)
>
>
>After discussion with the other reviewers: The draft is ambiguous with
>respect to byte-strings vs. bit-strings. My interpretation, stemming from
>the beginning of Section 4 explicitly mentioning byte-strings, is that
>all strings must be properly byte-aligned.
> But given that, using bytelen(additional_length) * 8 and
>bytelen(plaintext) * 8, i.e. bit-length, is confusing. If the draft is
>supposed to deal with byte-aligned strings only (which appears
>practically sensible), then this should be made clear in the document,
> and byte-length should be used in the encryption. Otherwise, the
>algorithms have to be specified more clearly for the case of bit-strings
>that are not byte-aligned. In either case, the draft should be clarified
>in this respect.
>
>
>
>
>
>On Tue, Jul 4, 2017 at 3:53 PM, Paterson, Kenny
><[e-mail]> wrote:
>
>Thanks everyone for this helpful discussion.
>
>If you want to update your reviews in the light of it, please go ahead and
>resend your reviews here. I'll then collate the three reviews we have to
>the CFRG list.
>
>Cheers
>
>Kenny
>
>On 04/07/2017 13:27, "Crypto-panel on behalf of Bjoern Tackmann"
><[e-mail] on behalf of
>[e-mail]>
>wrote:
>
>>Hi all,
>>
>>On Sun, Jul 2, 2017 at 2:37 PM, Tibor Jager
>><[e-mail]> wrote:
>>
>>
>>On 01/07/2017 20:34, Bjoern Tackmann wrote:
>>> 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.
>>
>>Indeed, this is one of the sections that suggests that it is implicitly
>>assumed that "valid" plaintexts and AD have always a byte-length which
>>is an integer.
>>
>>What I found *potentially* confusing is:
>>
>>- Then it would also be somewhat more intuitive/consistent to include
>>the byte-length of plaintext and AD in the length block. The current
>>draft includes the bit-length. (This is of course technically fine and
>>essentially just a different notation, but *could* be confusing.)
>>
>>- Also the example in Section 8 mentions the bit-length.
>>
>>
>>
>>
>>I fully agree that it would be less ambiguous to do these computations in
>>terms of byte-length. I do not see any advantage of having the scheme
>>operate internally in terms of bit-length, when only byte-length strings
>>are allowed.
>>
>>
>>
>>
>>- It would also make sense to let the encryption algorithm abort, if the
>>lengths of plaintexts and AD are not a multiple of 8 bits (and one could
>>ignore this check in applications where this is guaranteed by the
>>environment - but this is of course something that only the application
>>developer can decide).
>>
>>
>>
>>
>>Agreed.
>>
>>
>>
>>
>>Best,
>>Björn
>>
>>
>>
>>
>>
>>
>
>
>
>
>
>
>
>