Re: [CFRG] AEAD limits

[John Mattsson <[e-mail]>]

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 <[e-mail]>
Date: Tuesday, 17 November 2020 at 10:35
To: John Mattsson <[e-mail]>
Cc: Yoav Nir <[e-mail]>, "<[e-mail]>" <[e-mail]>
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=[e-mail]<mailto:[e-mail]>> 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:

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

Cheers,
John

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

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"
_______________________________________________
CFRG mailing list
[e-mail]<mailto:[e-mail]>
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
[e-mail]<mailto:[e-mail]>
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