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

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

Thanks Tibor - this is really helpful.

Cheers

Kenny 

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

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