[CFRG] Review of draft-irtf-cfrg-aead-limits-01

[John Mattsson <[e-mail]>]

Hi,

Great that you are taking the time to summarize all this information. Very useful.


Comments:

-- "plaintext, and optional associated data"
 
P and A are both optional in RFC 5116.


-- It would be good if the document states that it only focuses on "single forgery attacks"

I think some readers might believe that a second forgery is as hard as the first, which it is not. It it typically much easier. It might also vary drastically between algorithms as calculated in [1].


-- I think the document should briefly explain the assumptions about the adversary. For both CA and IA, one assumption worth explaining is that the adversary has access to an encryption oracle and can freely encrypt chosen-plaintexts.


-- The table defines l as "length of each message" while a paragraph further down writes "maximum message size (l)".


-- ”passive attacker”

For a reader that does now the IND-CPA game by heart it might be good to point out that the “passive” attacker does not just eavesdrop but also choses all the encrypted plaintexts.


-- “Integrity limit (IL): The number ciphertexts an application can decrypt, either successfully or not”

That IL also count successful decryptions seems to contradict other parts of the document that links IL to v which by definition only counts failed attempts.


-- “This implies the following usage limit: q + s <= p^(1/2) * 2^(129/2) – 1”
   “This implies the following limit: v <= (p * 2^127) / (l + 1)”

This does not follow with the current definition of p (p = CA or p = IA). To make the inequalities hold I think you need to define p as:
 
"Upper bound on adversary attack success probability"

just like the parameter epsilon in [AEBounds].


-- I think the document should briefly explain the assumptions about the algorithms. In [GCMProofs] it is e.g. assumed that AES is a PRP. Future cryptanalysis that does not make these ideal assumptions could make the limits worse.


-- The document should make it clear that formulas for CA and IA (at least for GCM) are upper bounds. Future analysis could make the limits better. That they are just bounds also make any direct comparision between algorithms tricky as some bounds might be tigher than others.


- The draft briefly mention that small limits lead to denial-of-service attacks. The DTLS 1.3 draft does that.


-- The draft seems to make the assumption that l is fixed like n, k, r. I don't think this needs to be the case. My understanding is that for the GCM limits, l_max_allowed can be replaced by l_max_seen being the largest length processed. The encryption or decryption function would then terminate when CA or IA can not be verified to be under the chosen bound. This would make a big difference for applications typically processing much smaller messages than for example 2^14. For the CCM integrity bounds, the formula would probably have to involve (2 * l_max_allowed * q + 2 * l_max_seen_* v). The DoS problem would still be tied to l_max_allowed.


Cheers,
John

[1]  https://csrc.nist.gov/CSRC/media/Projects/Block-Cipher-Techniques/documents/BCM/Comments/CWC-GCM/multi-forge-01.pdf