Re: [CFRG] AES-CTR + HMAC-SHA-256 AEAD

[Adam Langley <[e-mail]>]

On Fri, Mar 12, 2021 at 3:13 PM John Mattsson <john.mattsson=
[e-mail]> wrote:

> Hi,
>
> In the CFRG chat today, Richard Barnes asked for reviews of
> https://tools.ietf.org/html/draft-omara-sframe-01#section-4.5.1
>
> I think standardizing an AES-CTR + HMAC-SHA-256 AEAD seems very useful.
> The design in 4.5.1 looks very good. Some comments:
>
> - I think the nonce length Nn ciphersuite 1 and 2 should be 16. I don't
> see any reason to not use 16 bytes radnomness/salt.
>
> - It looks like the frame counter CTR and the block counter collide, but
> maybe I miss something.
>
> - I note that only the aad_len is authenticated, while GCM authenticated
> both aad_len and ct_len. I don't know what is correct.
>

I don't know what AES-CM is. Is it AES-CTR?

If so, isn't the AEAD authenticity completely broken because the nonce
isn't involved in computing the tag? I.e. if an attacker corrupts the nonce
in a (nonce, inner_ct, tag) tuple it looks like it'll decrypt "correctly"
but the plaintext will be random because the counter will be wrong.

When doing something similar
<https://boringssl.googlesource.com/boringssl/+/6b48efac7b3b229c17cff55e5cfd9f9a0aea9b70/crypto/cipher_extra/e_aesctrhmac.c#126>
I
also padded the HMAC input after the AAD and lengths to avoid the overhead
of phase-shifting all the ciphertext data when hashing it.


Cheers

AGL