Re: [CFRG] Comment on draft-irtf-cfrg-aead-limits-01

Thanks John,

We have planned to split the input length into two variables: one for the plaintext length, one for the AAD length.  This should help for those cases where the usage skews heavily toward one or the other and the bounds are substantially different based on that.

For instance, the CCM analysis counts plaintext as consuming 2 blocks and AAD as consuming 1.  For a protocol that mostly just authenticates, that might result in being able to send twice as many messages as an all encrypted protocol.  That's not a big deal, but then CCM bounds aren't exactly generous, so that might turn out to be useful.

On Tue, Nov 17, 2020, at 01:32, John Mattsson wrote:
> Hi,
> 
> The draft defines l as  "Length of each message (in blocks)" While 
> https://www.isg.rhul.ac.uk/~kp/TLS-AEbounds.pdf defines l as "input 
> length in blocks"
> 
> I assume the definition in the draft should be "input length in blocks" 
> and that the rewriting comes from TLS where A = "". It would also be 
> good to clearly define what "input" (or "message") is, none of the 
> terms are well-defined. Suggestion:
> 
> OLD    "Length of each message (in blocks)"
> NEW   ""input length (plaintext + additional authenticated data) in blocks"
> 
> (I assume https://www.isg.rhul.ac.uk/~kp/TLS-AEbounds.pdf means that 
> "input" is P and A, i.e. not K and N).
> 
> Cheers,
> John
> 
> 
>   
> 
> 
> 
> _______________________________________________
> CFRG mailing list
> CFRG@irtf.org
> https://www.irtf.org/mailman/listinfo/cfrg
>