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

[Adam Langley <[e-mail]>]

On Thu, Jan 19, 2017 at 2:19 AM, John Mattsson
<[e-mail]> wrote:
> - 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.

Thanks. I've added a TODO locally to think about this. I'm not sure
that we want to mention truncating authentication tags because that
seems contrary to the general thrust of robustness here. I'll see
whether I can say something about the advantages of the one-time
authentication keys in general however.

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

I don't understand why AES-GCM-SIV forces the processing of
unauthenticated plaintext. I think we might have different
definitions.

To me, processing authenticated plaintext means that the crypto API
releases plaintext for other processing before it has authenticated
it. It doesn't mean that the plaintext cannot sit in memory during
decryption while the AEAD checks the tag. (Indeed, many GCM
implementations interleave decryption and calculation of the GHASH
value.)

So putting the tag at the end prevents such APIs from being written,
which I think is a benefit.

A second benefit to putting tags at the end is that it's generally
easier to have extra space at the end of a buffer than the beginning.
This is not precise and might be a result of my C/C++/Go-based
environment, but I'm going to claim that a (buf, len, max) pattern is
easier for people to do with in an API than a (buf,
initial-padding-length, len).

In a case where space at the end of a buffer is easier to deal with,
putting the tag at the end is nicer because, otherwise,
encryption-in-place has to write ciphertext blocks 16 bytes in advance
of where it read them. In order to avoid clobbering the next plaintext
block, that has to copied first. I admit it's only a minor problem.

On the other hand, I'm not sure that I see the benefits of putting the
tag first in terms of latency on multicore machines. The AEAD model is
that the whole ciphertext is in memory when the operation is called so
it's as easy to read the tag from the end as from the beginning.

I can see an advantage in cases where the system could start
decrypting while the remainder of the record was still being read. Was
that what you had in mind? At least for multicore machines, I don't
think records should be so large that it makes a difference though.



Cheers

AGL