Subject: [CFRG] AEAD limits

From: Yoav Nir <[email-masked]>
Date: Tue, 17 Nov 2020 09:41:14 +0200

Following up on my mostly failed attempt to raise the issue at the meeting.

I still think we need to have, at least in an appendix, a table with actual limits in either bytes or packets.

Sure, this requires setting at least p and l.  p can be chosen arbitrarily (2^(-65)? 2^(-57)?), although I’d like an explanation of why a certain number makes sense.  l can be the row of the table.

For example, for p = 2^(-65) and l=1024 we get for AES-GCM that q<=2^22, so the table can show for this value of l 4 million packets and/or 4 GB.  For ChaCha20-Poly1305 you’d get v<=2^28 so you’d get 256 million packets or 256 GB.  With p at 2^(-57) you get other numbers. Still useful regardless or which value of p is chosen.

And one nit:  Please change the description of p in Table 1 from “Adversary attack probability” to “Adversary attack success probability"

---

From: John Mattsson <[email-masked]>
Date: Tue, 17 Nov 2020 09:06:52 +0000

Hi,

I think such a table would be a good idea. I think the table would be “example limits” rather than “actual limits” and should contain values for different values of p, l_p, and l_aad. This would give implementors (or people writing drafts) some guidance. It would also work like a form of test vectors. Without examples it is hard for a user of the document to check if they calculated the limits correctly.

For non-constrained environments where re-keying is easy, I think the conclusions are simple, don’t use CCM and re-key frequently. For the constrained IoT world (which currently use AES-CCM with 32 and 64 bit MACs), I think the analysis gets more complicated and I think there are a lot of other factors than p, l_p, and l_aad that needs to be considered. I tried to summarize this in a mail to LAKE:

https://mailarchive.ietf.org/arch/msg/lake/jxnTTX2L6HM9ZeVrQ4TNHdISulA/

Cheers,
John

-----Original Message-----
From: CFRG <[email-masked]> on behalf of Yoav Nir <[email-masked]>
Date: Tuesday, 17 November 2020 at 08:41
To: "<[email-masked]>" <[email-masked]>
Subject: [CFRG] AEAD limits

And one nit:  Please change the description of p in Table 1 from “Adversary attack probability” to “Adversary attack success probability" 
_______________________________________________
CFRG mailing list
[email-masked]
https://protect2.fireeye.com/v1/url?k=d31878d1-8c83419c-d318384a-86b568293eb5-e5d58f0c6ea46c4c&q=1&e=d3b7c45d-3795-4e54-888a-da4eb737f746&u=https%3A%2F%2Fwww.irtf.org%2Fmailman%2Flistinfo%2Fcfrg

---

From: Dmitry Belyavsky <[email-masked]>
Date: Tue, 17 Nov 2020 12:35:01 +0300

I agree with the idea of such a table, but do we really think it's stable
enough to make it a part of RFC?

On Tue, Nov 17, 2020 at 12:07 PM John Mattsson <john.mattsson=
[email-masked]> wrote:

> Hi,
>
> I think such a table would be a good idea. I think the table would be
> “example limits” rather than “actual limits” and should contain values for
> different values of p, l_p, and l_aad. This would give implementors (or
> people writing drafts) some guidance. It would also work like a form of
> test vectors. Without examples it is hard for a user of the document to
> check if they calculated the limits correctly.
>
> For non-constrained environments where re-keying is easy, I think the
> conclusions are simple, don’t use CCM and re-key frequently. For the
> constrained IoT world (which currently use AES-CCM with 32 and 64 bit
> MACs), I think the analysis gets more complicated and I think there are a
> lot of other factors than p, l_p, and l_aad that needs to be considered. I
> tried to summarize this in a mail to LAKE:
>
> I still think we need to have, at least in an appendix, a table with
> actual limits in either bytes or packets.
>
> Sure, this requires setting at least p and l.  p can be chosen arbitrarily
> (2^(-65)? 2^(-57)?), although I’d like an explanation of why a certain
> number makes sense.  l can be the row of the table.
>
> For example, for p = 2^(-65) and l=1024 we get for AES-GCM that q<=2^22,
> so the table can show for this value of l 4 million packets and/or 4 GB.
> For ChaCha20-Poly1305 you’d get v<=2^28 so you’d get 256 million packets or
> 256 GB.  With p at 2^(-57) you get other numbers. Still useful regardless
> or which value of p is chosen.
>
> And one nit:  Please change the description of p in Table 1 from
> “Adversary attack probability” to “Adversary attack success probability"
> https://www.irtf.org/mailman/listinfo/cfrg
>

-- 
SY, Dmitry Belyavsky

---

From: John Mattsson <[email-masked]>
Date: Tue, 17 Nov 2020 18:27:22 +0000

If the draft calculates v and q for different values of p, l_p, and l_add, they would be as stable as the equations themselves.

John

From: Dmitry Belyavsky <[email-masked]>
Date: Tuesday, 17 November 2020 at 10:35
To: John Mattsson <[email-masked]>
Cc: Yoav Nir <[email-masked]>, "<[email-masked]>" <[email-masked]>
Subject: Re: [CFRG] AEAD limits

I agree with the idea of such a table, but do we really think it's stable enough to make it a part of RFC?

On Tue, Nov 17, 2020 at 12:07 PM John Mattsson <john.mattsson=[email-masked]<mailto:[email-masked]>> wrote:
Hi,

Cheers,
John

-----Original Message-----
From: CFRG <[email-masked]<mailto:[email-masked]>> on behalf of Yoav Nir <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, 17 November 2020 at 08:41
To: "<[email-masked]<mailto:[email-masked]>>" <[email-masked]<mailto:[email-masked]>>
Subject: [CFRG] AEAD limits

And one nit:  Please change the description of p in Table 1 from “Adversary attack probability” to “Adversary attack success probability"
_______________________________________________
CFRG mailing list
[email-masked]<mailto:[email-masked]>
https://protect2.fireeye.com/v1/url?k=d31878d1-8c83419c-d318384a-86b568293eb5-e5d58f0c6ea46c4c&q=1&e=d3b7c45d-3795-4e54-888a-da4eb737f746&u=https%3A%2F%2Fwww.irtf.org%2Fmailman%2Flistinfo%2Fcfrg

_______________________________________________
CFRG mailing list
[email-masked]<mailto:[email-masked]>
https://www.irtf.org/mailman/listinfo/cfrg<https://protect2.fireeye.com/v1/url?k=8e52694e-d1c95048-8e5229d5-86ee86bd5107-fe864896a21f2058&q=1&e=ba3a0fa2-5c12-463e-81af-fea783bcbc92&u=https%3A%2F%2Fwww.irtf.org%2Fmailman%2Flistinfo%2Fcfrg>

--
SY, Dmitry Belyavsky