core-wg / oscore-key-limits

Other
0 stars 0 forks source link

Redefine 'l', 'limit_q', and 'limit_v' specifically for OSCORE #8

Closed rikard-sics closed 2 weeks ago

rikard-sics commented 2 years ago

Based on feedback from John during the CoRE interim on April 28.

Currently we are using l = 2^10, dropping that to 2^8 may be beneficial.

Furthermore we can define set values for 'limit_q' and 'limit_v', not relying on the CFRG document.

For instance setting an overall value for 'limit_q' to 2^20 (which is lower than all the calculated limits for q we have currently).

As long as we reduce values, like reducing the size of l and the size of 'limit_q' things should be easy to motivate as we are erring more on the side of caution.

When it comes to redefining 'limit_v' we actually want to increase this value and here is where we need a good motivation. We can start a discussion on the mailing list based on the figures John presented. He also promised to contribute material in the form of a PR to the draft.

rikard-sics commented 2 years ago

After further discussions we can use l = 2^8, q = 2^20 and v = 2^20, also considering the material presented by John during a SAAG meeting. See https://datatracker.ietf.org/meeting/110/materials/slides-110-saag-analysis-of-usage-limits-of-aead-algorithms-00.pdf

This can mean that we use the formulas for calculating IA and CA from the CFRG document with these values and show that the resulting probabilities are safe (<2^-64).

rikard-sics commented 2 years ago

Double check calculations in the table, especially for AES CCM 8 with John.

rikard-sics commented 2 weeks ago

We have our own calculated probabilities now.

Any further diverging from what the CRFG document says need strong motivation. Further discussion with John is already another issue in https://github.com/core-wg/oscore-key-limits/issues/2