Subject: [CFRG] Can you help me with this?

From: Adnan Rashid <[email-masked]>
Date: Sat, 24 Jul 2021 17:03:51 +0200

Hi Everyone,

I am new and have few questions, My questions are regarding the AEAD.

*Questions:*

   1. A *nonce* can be (Counter. LFSR, Timestamp, A sequence number, or
   some combination of these.) Is it possible if we can use them as *aad? **aad
   *can also be a sequence number, written in rfc5116.
   2. If yes then what would be a vulnerability?
   3. How do Alice and Bob know the exact nonce for a particular packet?
   Because packets may be dropped.

Regards,

ADNAN

---

From: Soatok Dreamseeker <[email-masked]>
Date: Sat, 24 Jul 2021 19:00:04 -0400

1. If you want, you can include the nonce in the AAD. In fact, this is
necessary in constructions such as CBC+HMAC to prevent attackers from
getting free reign over the first 16 bytes of the plaintext.
2. That's a very open question.
3. Check out the TLS 1.3 RFC for specifics.

Happy to continue this conversation off-list.

On Sat, Jul 24, 2021 at 11:05 AM Adnan Rashid <[email-masked]>
wrote:

>    some combination of these.) Is it possible if we can use them as
>    *aad? **aad *can also be a sequence number, written in rfc5116.
> _______________________________________________
> CFRG mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/cfrg
>

---

From: "Scott Fluhrer (sfluhrer)" <[email-masked]>
Date: Sun, 25 Jul 2021 17:56:26 +0000

“Read the TLS RFC” isn’t a great answer, because TLS assumes a reliable transport; that is, records won’t be dropped or reordered (absent enemy action).  That assumption is mentioned in the first sentence of the introduction of the RFC, but the implications are not spelled out.

Certainly, assuming a reliable transport is one viable approach.  However, if you can’t make that assumption (and sometimes we can’t), what we do is include the nonce in the encrypted packet; that way, it doesn’t matter if previous packets were dropped, as the current packet has sufficient context (that is, nonce) for the receiver to decrypt.

From: CFRG <[email-masked]> On Behalf Of Soatok Dreamseeker
Sent: Saturday, July 24, 2021 7:00 PM
To: Adnan Rashid <[email-masked]>
Cc: [email-masked]
Subject: Re: [CFRG] Can you help me with this?

Questions:

  1.  How do Alice and Bob know the exact nonce for a particular packet? Because packets may be dropped.

Regards,
ADNAN

_______________________________________________
CFRG mailing list
[email-masked]<mailto:[email-masked]>
https://www.irtf.org/mailman/listinfo/cfrg

---

From: Adnan Rashid <[email-masked]>
Date: Sun, 25 Jul 2021 19:59:06 +0200

I am on it. Thanks Scott. 😊

Regards,

Adnan Rashid

On Sun, Jul 25, 2021, 19:56 Scott Fluhrer (sfluhrer) <[email-masked]>
wrote:

> “Read the TLS RFC” isn’t a great answer, because TLS assumes a reliable
> transport; that is, records won’t be dropped or reordered (absent enemy
> action).  That assumption is mentioned in the first sentence of the
> introduction of the RFC, but the implications are not spelled out.
>
>
>
> Certainly, assuming a reliable transport is one viable approach.  However,
> if you can’t make that assumption (and sometimes we can’t), what we do is
> include the nonce in the encrypted packet; that way, it doesn’t matter if
> previous packets were dropped, as the current packet has sufficient context
> (that is, nonce) for the receiver to decrypt.
>
>
>
> *From:* CFRG <[email-masked]> *On Behalf Of *Soatok Dreamseeker
> *Sent:* Saturday, July 24, 2021 7:00 PM
> *To:* Adnan Rashid <[email-masked]>
> *Cc:* [email-masked]
> *Subject:* Re: [CFRG] Can you help me with this?
>
>
>

---

From: "David McGrew (mcgrew)" <[email-masked]>
Date: Sun, 25 Jul 2021 21:57:57 +0000

Hi Soatok and Adnan,

From https://datatracker.ietf.org/doc/html/rfc5116#section-2.1, the associated data "contains the data to be authenticated, but not encrypted.”   Associated data has the same meaning as additional authenticated data, or AAD.    In other words, AAD is data associated with the plaintext to be encrypted, which is not encrypted.   For instance, if you are encrypting files, and you want to authenticate the file name so that someone who performs the authenticated decryption operation would detect a modification of the file name, then the file name would go into the AAD.

On Jul 24, 2021, at 4:00 PM, Soatok Dreamseeker <[email-masked]<mailto:[email-masked]>> wrote:

1. If you want, you can include the nonce in the AAD. In fact, this is necessary in constructions such as CBC+HMAC to prevent attackers from getting free reign over the first 16 bytes of the plaintext.

That’s not right; it would be wrong to define an AEAD construction that required the nonce to go into the AAD.  It should be sufficient that the nonce is distinct.

Side note: from the IANA registry, it looks as though no one has registered a CBC+HMAC construction  https://www.iana.org/assignments/aead-parameters/aead-parameters.xhtml#aead-parameters-2

On Sat, Jul 24, 2021 at 11:05 AM Adnan Rashid <[email-masked]<mailto:[email-masked]>> wrote:
Hi Everyone,

Questions:

  1.  A nonce can be (Counter. LFSR, Timestamp, A sequence number, or some combination of these.)

Right.

  1.  Is it possible if we can use them as aad? aad can also be a sequence number, written in rfc5116.

You can put anything you want into the AAD field, but you don’t have to put anything into it.   You probably only want to have a data element in the AAD field if an attacker could cause something bad to happen by forging or spoofing that data element.   If there is no associated data that needs to be authenticated, just leave that input empty (that is, have it be zero length).

Best

David

  1.  If yes then what would be a vulnerability?
  2.  How do Alice and Bob know the exact nonce for a particular packet? Because packets may be dropped.

Regards,

ADNAN