cfrg / draft-irtf-cfrg-aead-limits

Usage Limits on AEAD Algorithms
https://cfrg.github.io/draft-irtf-cfrg-aead-limits/draft-wood-cfrg-aead-limits.html
Other
7 stars 6 forks source link

Provide more examples #45

Open thomas-fossati opened 2 years ago

thomas-fossati commented 2 years ago

We want to compute the limits for AES-GCM in (D)TLS 1.2.

Previously we thought the figures would be identical to 1.3, but then "Partial implicit nonces" PR made us realise that things were slightly more complicated than we had anticipated.

So, I am looking at the inequalities in Section 6.1 for "Protocols with random, partially implicit nonces" -- and this one in particular:

AEA <= (((q+v)*o + (q+v)^2) / 2^(k+26)) + ((q+v)*l*B / 2^127)

First, fresh impression: once you go one step beyond the deceivingly simple math, there is a surprisingly high number of practical assumptions one needs to do in to pull out a number! :-)

So, before writing down any silly things in 7525bis, I'd like to validate my thought process with you.

First of all, since the bounds are for a M-U context and I'd rather have results for single-user so that are comparable with the existing bounds for 1.3, is it possible to reuse the results for the special case M=1? Or does that kill any fundamental premise which the analysis is built upon?

Assuming it's OK (optimistic hat on):

Then

And the sought after bounds:

We can now plug all of the above into the inequality, which gives:

Is this sensible? Can you spot any flaws?

martinthomson commented 2 years ago

I think that it would make sense to pick values rounded to powers of 2 for simplicity. That is, B = q.2^7 and IA and CA of 2^-57.

With that in mind, you have (for DTLS)

2^-57 >=  5q^2/2^154 +  2q^2.2^14/2^127
      =~ (5 + 2^42).q^2/2^154

Dropping the 5 as insignificant, that puts q at 2^27.5, which I guess confirms your answer.

The same numbers used with the single user analysis produce q =~ 2^28 and v =~ 2^63, so that is also consistent.

Yes, using this stuff in any sensible fashion requires assembling a massive pile of assumptions. Most of them, like me dropping the 5, are small approximations that we make in order to make problems more tractable and usable. But the targets are also loose and probabilistic. When we set a target of 2^-57, we don't know for sure that that exact number is needed. Indeed, that number is the product of nothing more than guesswork.

The goal is to ensure that we keep a sizeable safety margin; the size of that margin can be subjective. For instance, if you want to use CCM_8 with a lower margin, this gives you the tools to set a margin according to your tolerance for risk and apply limits that will maintain that margin.

thomas-fossati commented 2 years ago

Thanks very much for checking, really appreciated. And thank you for the laudable initiative of funnelling & processing the available literature in a single document.

As an early user of this document, I might have a suggestion: it'd be good to collect "common case" values for the parameters in a table, so that one doesn't have to scan the document back and forth or make up their own, and possibly use those to provide simplified formulas -- e.g., something similar to Appendix B.2 of NIST's CCM recommendations.

martinthomson commented 2 years ago

The examples were intended to be representative of some common and useful cases. We could add more.

chris-wood commented 2 years ago

Reframing this issue to focus on providing more examples in the document. This would be nice to do, but is not necessary.