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

From: John Mattsson <[email-masked]>
Date: Fri, 12 Mar 2021 23:12:38 +0000

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.

Cheers,
John

---

From: Adam Langley <[email-masked]>
Date: Fri, 12 Mar 2021 15:44:38 -0800

On Fri, Mar 12, 2021 at 3:13 PM John Mattsson <john.mattsson=
[email-masked]> 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.
>
> - 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

---

From: John Mattsson <[email-masked]>
Date: Sat, 13 Mar 2021 08:14:56 +0000

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

Yes, Counter Mode (CM) is just CTR. The terminology CM was used in RFC 3711 (SRTP) and McGrew’s paper from the same time. https://cr.yp.to/bib/2002/mcgrew.pdf.

I wrote:
“It looks like the frame counter CTR and the block counter collide, but maybe I miss something.”.

A better description is probably that it is undefined how the 12 byte nonce is mapped to the 16 byte IV in AES counter mode. I would recommend:

frame_ctr = encode_big_endian(CTR * 2^64, 16)

From: Adam Langley <[email-masked]>
Date: Saturday, 13 March 2021 at 00:45
To: John Mattsson <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [CFRG] AES-CTR + HMAC-SHA-256 AEAD

On Fri, Mar 12, 2021 at 3:13 PM John Mattsson <john.mattsson=[email-masked]<mailto:[email-masked]>> wrote:
Hi,

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

---

From: Adam Langley <[email-masked]>
Date: Mon, 15 Mar 2021 09:43:58 -0700

On Sat, Mar 13, 2021 at 12:15 AM John Mattsson <john.mattsson=
[email-masked]> wrote:

> Yes, Counter Mode (CM) is just CTR. The terminology CM was used in RFC
> 3711 (SRTP) and McGrew’s paper from the same time.
> https://cr.yp.to/bib/2002/mcgrew.pdf.
>
>
>
>
>
> I wrote:
>
> A better description is probably that it is undefined how the 12 byte
> nonce is mapped to the 16 byte IV in AES counter mode. I would recommend:
>
>
>

I think it's more than underspecified, I don't think it meets basic AEAD
requirements. I'll contact the authors about that.

Cheers

AGL

---

From: Nico Williams <[email-masked]>
Date: Mon, 15 Mar 2021 12:41:08 -0500

On Fri, Mar 12, 2021 at 11:12:38PM +0000, John Mattsson wrote:
> 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. 
> 
> - 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 would consider (and maybe discard or alter) the Kerberos approach to
this, which is: confounded CTS (CipheText Staling) mode with
MAC-then-encrypt (should be encrypt-then-MAC) with HMAC.

Confounding means that you prepend a block of random (or chained) IV to
the plaintext, then encrypt the resulting plaintext.  Confounding,
instead of a normal IV, is necessary in order to have a plaintext of at
least two cipher blocks when the actual plaintext is less than one
block.  CTS means no plaintext padding is needed.

Nico
--