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

From: "Paterson, Kenny" <[email-masked]>
Date: Thu, 15 Jun 2017 14:38:26 +0000

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

---

From: "Paterson, Kenny" <[email-masked]>
Date: Thu, 15 Jun 2017 14:43:10 +0000

Sorry, that should be
https://tools.ietf.org/html/draft-irtf-cfrg-gcmsiv-05 (and not -04).

---

From: Tibor Jager <[email-masked]>
Date: Thu, 15 Jun 2017 17:12:13 +0200

Hi Kenny,

I can have a look at the draft, I wanted to read the paper anyway.

Cheers,
Tibor

--
Sent from a mobile device. Please excuse brevity.

Am 15.06.2017 16:38 schrieb "Paterson, Kenny" <[email-masked]>:

Dear CFRG panel members,

Let me know.

Cheers,

Kenny

_______________________________________________
Crypto-panel mailing list
[email-masked]
https://www.irtf.org/mailman/listinfo/crypto-panel

---

From: "Scott Fluhrer (sfluhrer)" <[email-masked]>
Date: Thu, 15 Jun 2017 15:13:17 +0000

I'll take a look at it as well...

> -----Original Message-----
> From: Crypto-panel [mailto:[email-masked]] On Behalf Of
> Paterson, Kenny
> Sent: Thursday, June 15, 2017 10:43 AM
> To: Paterson, Kenny; [email-masked]
> Cc: [email-masked]
> Subject: Re: [Crypto-panel] Review of AES-GCM-SIV
> 
> Sorry, that should be
> >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.
> >

---

From: Russ Housley <[email-masked]>
Date: Thu, 15 Jun 2017 11:14:46 -0400

Seems like you have two.  If you need more, please say something.

Russ

> On Jun 15, 2017, at 10:38 AM, Paterson, Kenny <[email-masked]> wrote:
> 
> Dear CFRG panel members,
>

---

From: Bjoern Tackmann <[email-masked]>
Date: Thu, 15 Jun 2017 17:15:03 +0200

Will be happy to help here -- my calendar estimates that I will need a bit
more than one week, but not more than two.

---

From: "Stanislav V. Smyshlyaev" <[email-masked]>
Date: Thu, 15 Jun 2017 18:32:56 +0300

Dear colleagues,

Same position as in Russ' message – there are 3 reviewers already, but if
the fourth one is needed, I'll be happy to help.

Kindest regards,
Stanislav

2017-06-15 18:15 GMT+03:00 Bjoern Tackmann <[email-masked]>:

> On Thu, Jun 15, 2017 at 4:43 PM, Paterson, Kenny <
> [email-masked]> wrote:
>
>> Sorry, that should be
>> from

---

From: "Paterson, Kenny" <[email-masked]>
Date: Thu, 15 Jun 2017 15:59:12 +0000

Thanks everyone for the quick replies.

Having three reviews on this from Tibor, Bjoern and Scott will be excellent.

Regards,

Kenny

Sent from my iPhone

On 15 Jun 2017, at 16:33, Stanislav V. Smyshlyaev <[email-masked]<mailto:[email-masked]>> wrote:

Dear colleagues,

Same position as in Russ' message – there are 3 reviewers already, but if the fourth one is needed, I'll be happy to help.

Kindest regards,
Stanislav

2017-06-15 18:15 GMT+03:00 Bjoern Tackmann <[email-masked]<mailto:[email-masked]>>:
Will be happy to help here -- my calendar estimates that I will need a bit more than one week, but not more than two.

On Thu, Jun 15, 2017 at 4:43 PM, Paterson, Kenny <[email-masked]<mailto:[email-masked]>> wrote:
Sorry, that should be
https://tools.ietf.org/html/draft-irtf-cfrg-gcmsiv-05 (and not -04).

_______________________________________________
Crypto-panel mailing list
[email-masked]<mailto:[email-masked]>
https://www.irtf.org/mailman/listinfo/crypto-panel

_______________________________________________
Crypto-panel mailing list
[email-masked]<mailto:[email-masked]>
https://www.irtf.org/mailman/listinfo/crypto-panel

---

From: "Scott Fluhrer (sfluhrer)" <[email-masked]>
Date: Mon, 19 Jun 2017 14:05:50 +0000

My review:

Summary: Almost Ready

Major Concerns:

None - from a security perspective, it looks pretty good

Minor Concern:

One thing that may be problematic to an implementor was the nonces listed in the test vectors.  AES-GCM-SIV takes 12 byte nonces, the nonces listed are 16 bytes long.  While this is unlikely to be a major source of confusion for an implementator, I suggest that the nonces be trimmed down before publishing.

Nits:

The encryption/decryption algorithms are given using fairly terse English descriptions.  While they are moderately clear to me, I wonder if they'd be as clear to someone else; I'm wondering if a pseudocode description would work better?  On the other hand, the test vectors give intermediate cipherstates (which would help a lot).

While the test vectors are quite good in general, they use only one nonce, and two keys (one for each key length).  While there is certainly value in reusing the same key and nonce for slightly different plaintexts/AADs, I believe there would also be value in showing how different keys/nonces work.  One example: at one point,  AES-GCM-SIV xor's in the nonce into the POLYVAL result.  If someone did an incorrect implementation where (say) they exclusive-or'ed only the first 4 or 8 bytes of the nonce, the current test vectors would still pass.

The bytes in the test vector are listed LSB to MSB.  This rather assumes that the implementor is using little-endian byte ordering; I would suggest that this be changed to a more endian-neutral notation (possibly by just omitted the LSB and MSB labels).

---

From: "Paterson, Kenny" <[email-masked]>
Date: Mon, 19 Jun 2017 16:38:33 +0000

Thanks Scott. Once all the reviews are in, we'll collate them and post
them to the list.

On 19/06/2017 15:05, "Scott Fluhrer (sfluhrer)" <[email-masked]> wrote:

>One thing that may be problematic to an implementor was the nonces listed
>in the test vectors.  AES-GCM-SIV takes 12 byte nonces, the nonces listed
>are 16 bytes long.  While this is unlikely to be a major source of
>confusion for an implementator, I suggest that the nonces be trimmed down
>before publishing.
>
>
>Nits:
>
>The encryption/decryption algorithms are given using fairly terse English
>descriptions.  While they are moderately clear to me, I wonder if they'd
>be as clear to someone else; I'm wondering if a pseudocode description
>would work better?  On the other hand, the test vectors give intermediate
>cipherstates (which would help a lot).
>
>While the test vectors are quite good in general, they use only one
>nonce, and two keys (one for each key length).  While there is certainly
>value in reusing the same key and nonce for slightly different
>plaintexts/AADs, I believe there would also be value in showing how
>different keys/nonces work.  One example: at one point,  AES-GCM-SIV
>xor's in the nonce into the POLYVAL result.  If someone did an incorrect
>implementation where (say) they exclusive-or'ed only the first 4 or 8
>bytes of the nonce, the current test vectors would still pass.
>
>The bytes in the test vector are listed LSB to MSB.  This rather assumes
>that the implementor is using little-endian byte ordering; I would
>suggest that this be changed to a more endian-neutral notation (possibly
>by just omitted the LSB and MSB labels).
>
>
>

---

From: "Paterson, Kenny" <[email-masked]>
Date: Wed, 21 Jun 2017 13:36:29 +0000

Dear CFRG panel members,

Alexey and I would like to ask for volunteers from the panel to perform
reviews of the Argon2 draft:

https://datatracker.ietf.org/doc/draft-irtf-cfrg-argon2/

We'd like to move this one to last call, and having a couple of reviews
from the crypto panel would help give us the confidence to do so.

Thanks in advance,

Kenny

---

From: "Stanislav V. Smyshlyaev" <[email-masked]>
Date: Wed, 21 Jun 2017 16:46:10 +0300

Dear Kenny,

I'll be happy to do this.

I'll be able to provide a review by the 9th of July (please tell me if it's
preferred to be done earlier - it won't be a big problem).

Best regards,
Stanislav

---

From: Tibor Jager <[email-masked]>
Date: Thu, 22 Jun 2017 15:27:59 +0200

Hi all,

Please find my review below:

================================================================================

Summary: almost ready

========================================
Major concerns:
========================================

none

========================================
Minor comments and recommendations:
========================================

Section 4, first paragraph after the pseudocode:

The length block contains the length of the plaintext and the length of
the additional data (AD), computed as

  bytelen(plaintext)*8  and  bytelen(AD)*8, repectively

Is it possible to encrypt such that the length in *bits* of either the
plaintext or the AD is not a multiple of 8? If yes, then how exactly is
the bytelen() function defined in this case?

For example, let C = Enc(k,m,d,n) be a ciphertext, encrypting plaintext
m with key k, nonce n, and additional data d. Suppose that |d| = 7 bits,
and that bytelen() is implemented such that bytelen(d) = 1 (which may
happen, if bytelen() returns only integers, even tough bytelen(d) = 7/8
would actually be correct). Note that then the encryption algorithm pads
d with one zero, and we have bytelen(d||0) = 1, too. Therefore it holds that

  C = Enc(k,m,d,n) = Enc(k,m,d||0,n)

and the decryption algorithm accepts both d and d||0 as "valid"
additional data for C. (A similar attack may be possible to modify
plaintexts, too.)

Depending on the application, this may pose a security issue, or at
least an implementational difficulty, because it is natural to implement
a bytelen() function in a way such that it returns only integers. (In
particular if a developer only has plaintexts/ADs in mind whose size is
a multiple of 8 bits, even though an application may permit other
plaintext/AD sizes).

Recommendations:
(a) If plaintexts and AD may have bit-lengths which are not a multiple
of 8 (which is somewhat suggested by the statement "plaintexts can have
arbitrary length" in the 1st paragraph of Section 4, and by the fact
that the example
in section 8 talks about the *bit*-length of the plaintext), then the
bytelen() function
should be replaced with a bitlen() function.
(b) Alternatively, if it is implicitly assumed that the lenghts of
plaintext and AD in *bits* is always a multiple of 8 (which may be
reasonable for most applications), then this should be clarified in the
RFC. Then either encryption woukd fail if plaintext or AD do not have
appropriate length, or it should be decribed how plaintext/AD can be
padded to appropriate length.

I think that (a) seems preferable, because it seems simpler, more
general, and appropriate for an encryption scheme based on counter mode
that permits arbitrary-length plaintexts.

========================================
Nitpicking:
========================================

Section 1 "Introduction", 1st paragraph: I suggest to replace
  "...that is easier for practitioners to use correctly."
with
  "that is easier to use correctly."

In Section 4, first paragraph, the text suggests that plaintexts and
additional data of arbitrary length can be encrypted. However, the
description of the decryption procedure in Section 5 rejects ciphertexts
of size larger than 2^36+16 bytes, and Section 6 gives upper bounds on
the plaintext and AD sizes P_MAX and A_MAX.

In Section 4, last paragraph, the result of encryption is the "resulting
ciphertext ... followed by the tag". Thus, in this notation, the tag is
not part of the "ciphertext", but it is separate and sent along with the
ciphertext.
However, at the beginning of Section 5, decryption algorithm receives as
input key, nonce, AD, and a ciphertext, and the ciphertext is split into
the encrypted plaintext and the tag, thus the "ciphertext" contains the
tag here. One could unify this, by always considering the tag as part of
the ciphertext.

Section 8, very very nitpicking: One could mention here that the
plaintext are the bit strings corresponding to the *ASCII encoding* of
"Hello world" and "example".

Section 8, 5th paragraph, again very nitpicking: Some developers may
have difficulties in understanding immediately which numbers are given
in hexadecimal notation, and which in decimal notation. For clarity, one
could write here something like:
"example": 7 characters = 56 bits = 0x38 bits
"Hello world": 11 characters = 88 bits = 0x58 bits

Section 9, 7th paragraph: "Suzuki et al. [multibirthday]", the reference
lists Kazuhiro as first author, so it seems this should be Kazuhiro et al.

I did not check the test vectors.

Regarding Scott's comment on the verbal description of the encryption
and decryption algorithms: I had the same impression, some pseudocode
may be helpful to clarify what is happening here.

Apart from the above minor comments, I think that this is an excellent
RFC, which is very clear, precise, easy to understand, and
well-readable. The large number of test vectors will certainly be
considered very helpful to many implementers. I think it is very useful
to have a nonce misuse-resistant encryption scheme defined in an RFC, in
particular if it is as competitive with weaker solutions regarding
implementational difficulty and computational efficiency as this one.

================================================================================

Cheers,
Tibor

---

From: "Paterson, Kenny" <[email-masked]>
Date: Thu, 22 Jun 2017 14:32:07 +0000

Thanks Tibor - this is really helpful.

Cheers

Kenny 

On 22/06/2017 14:19, "Tibor Jager" <[email-masked]> wrote:

>of 8, then the bytelen() function should be replaced with a bitlen()
>function.