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

[John Mattsson <[e-mail]>]

Hi Adam,

Thanks for addressing my comments so fast! One more comment:

- The use of one-time authentication keys has the benefit that it
mitigates Fergusson’s authentication key recovery attack on GCM in the
two-party case. In case of multicast the attack remains (but significantly
restricted). This makes GCM-SIV a little bit more suitable for truncated
tags than GCM. I think these advantages should be mentioned.

- See reply on tag placement inline.

Cheers,
John




On 2017-01-19, 01:13, "[e-mail] on behalf of Adam Langley"
<[e-mail] on behalf of [e-mail]> wrote:

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

I would agree with you if placing the tag last actually improved anything,
but the fact is that GCM-SIV actually forces processing of unauthenticated
ciphertext by design (a change from GCM). I cannot see any security
benefits with (C, T) compared to (T, C). The only difference I can see is
that (C, T) increases the latency for decryption on multicore.

>
>>   - 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/c6c7fd388dd122251264222b7491c6212e818
>319.)
>
>> - “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