-
Notifications
You must be signed in to change notification settings - Fork 6
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
Comments
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)
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. |
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. |
The examples were intended to be representative of some common and useful cases. We could add more. |
Reframing this issue to focus on providing more examples in the document. This would be nice to do, but is not necessary. |
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:
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?
The text was updated successfully, but these errors were encountered: