Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Provide more examples #45

Open
thomas-fossati opened this issue Sep 28, 2021 · 4 comments
Open

Provide more examples #45

thomas-fossati opened this issue Sep 28, 2021 · 4 comments

Comments

@thomas-fossati
Copy link
Contributor

thomas-fossati commented Sep 28, 2021

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):

  • o := q+v (attacker willing to spend the same effort as the legitimate user)
  • l := 2^7 (message size of one Internet MTU)
  • B := 1500/16*q (message size of one Internet MTU over 16 bytes AES block size)

Then

  • q := v (equal proportions for q and v for DTLS)
  • v := 1 (one failed verification at most for TLS)

And the sought after bounds:

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

  • DTLS, AES-GCM-128: q = v = 2.3771*10^8 ~= 2^28
  • DTLS, AES-GCM-256: q = v = 2.3771*10^8 ~= 2^28
  • TLS, AES-GCM-128: q = 3.36173*10^8 ~= 2^28
  • TLS, AES-GCM-256: q = 3.36173*10^8 ~= 2^28

Is this sensible? Can you spot any flaws?

@martinthomson
Copy link
Collaborator

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
Copy link
Contributor Author

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
Copy link
Collaborator

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

@chris-wood chris-wood changed the title Computing bounds for TLS 1.2 Provide more examples Jul 11, 2022
@chris-wood
Copy link
Collaborator

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants