Re: [Cfrg] I-D Action: draft-irtf-cfrg-gcmsiv-03.txt

[Adam Langley <[e-mail]>]

On Wed, Jan 18, 2017 at 1:05 PM, John Mattsson
<[e-mail]> wrote:
> - In addition to listing the performance penalty compared to GCM. The
>   draft should also mention that compared to GCM, some nice properties
>   disappear:
>   - Neither Encryption nor Decryption is online as encryption/decryption
>     cannot start before the whole plaintext/ciphertext is known.

I agree that this is true for encryption, but I don't believe that
AES-GCM should be *de*crypted in a streaming fashion, but rather that
records should be sized so that this isn't a problem. (At which point
the benefit for streaming encryption becomes small or moot.)

I've a long spiel about the dangers of processing unauthenticated
ciphertext which I'll spare you :) But, even for small machines, the
memory needed to safely buffer the decrypted plaintext to avoid
releasing it before it's authenticated is equal to the memory to
buffer the ciphertext followed by decrypting in-place.

So I actually quite like that the tag is at the end of the message
with AES-GCM-SIV because it makes it harder to do what I think is the
"wrong" thing.

>   - GCM-SIV removes the possibility to preprocess static headers (AAD).

Indeed.

(I wasn't sure where to put these points in the spec so, for the
moment, I've added an appendix for "Additional comparisons with
AES-GCM". I'm collecting changes in GitHub before making a new
version. For this message, see
https://github.com/agl/gcmsiv/commit/c6c7fd388dd122251264222b7491c6212e818319.)

> - “The result of the encryption is the resulting ciphertext (truncated
>    to the length of the plaintext) followed by the tag."
>
>   I suggest that the tag is placed first instead of last in the
>   ciphertext. This makes decryption online, which makes a large
>   difference. Suggestion:
>
>   “The result of the encryption is the tag followed by the ciphertext
>    (truncated to the length of the plaintext)"

(See above.)

>
>
> - "within 5% of the speed of AES-GCM."
>   Should state when this is the case, e.g. long plaintext/aad.

Done.

>
> - I think the draft should give performance data also for short
>   plaintexts/aad or even better list the performance in number of
>   operations:
>
>   GCM:
>     Block Cipher Operations = p + 1
>     GF(2^128) Multiplications = p + a + 1
>
>   GCM-SIV-128
>     Block Cipher Operations = p + 5
>     GF(2^128) Multiplications = p + a + 1
>
>   GCM-SIV-256
>     Block Cipher Operations = p + 7
>     GF(2^128) Multiplications = p + a + 1
>
>   (if I got it right...)

I think that's correct and I've added that to the new appendix.

>   Where p is the block length of the plaintext and a is the block length
>   of the additional authenticated data,
>
>   I doubt that encryption of short messages are anywhere near 5% of GCM.
>
> - The "++" and "[:8]" operation should probably be defined.

Done.

>
> - What it the security/performance tradeoff with truncation in the key
>   derivation? What would the security properties be if "[:8]" was
>   removed?

I'll have to let Shay answer this, but the rough idea is that, since
AES is a permutation, not two ciphertexts can be equal given that
we're encrypting different plaintexts using the KDF phase. However,
ideally we would want a PRF where outputs can be the same. By taking
only the first eight bytes of each ciphertext block, we better
approximate a PRF.

> - The definition of U32LE seems unnecessary and only adds complexity.
>   I suggest:
>     OLD "U32LE(3) ++ nonce"
>     NEW "03 ++ 000000 ++ nonce

Good point.

>
> - The term K1 is only used in Test Vectors. I guess it is an old term
>   that should be removed.

Done.

> Some editorials:

Thank you for all these. They should be taken care of.

> - OLD "The record-authentication key is 128-bit and the
>        record-authentication key"
>   NEW "The record-authentication key is 128-bit and the
>        record-encryption key"
>
> - "} else if bytelen(key-generating-key) == 32 {
>      record-encryption-key = AES128(key = key-generating-key,"
>
>   Should be AES256

Indeed, and record-authentication-key is wrong too!

> - Spacing around "+" and "*" are not consistent.
>
> - "the the"
>
> - yeilds
>
> - remainding
>
> - RFC7322 says "A comma is used before the last item of a series"

I think I've leave this one to the RFC Editor!



Cheers

AGL