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

[Felix Günther <[e-mail]>]

Hi,


On 2025-03-12 22:46 +0100, Mihir Bellare 
<mbellare=[e-mail]> wrote:
>     That is, if you set a target advantage of 2^-50, then you are
>     inherently assuming that o is significantly less than 2^n*2^-50 or
>     that term would be what determines the advantage that an attacker
>     gains.  Would that sort of thing help?
> 
> 
> Fixing a particular target advantage, and hence a value of o, feels a 
> bit arbitrary and hard for non-cryptographers to understand intuitively.

Right, indeed we'll add a discussion of how offline work places an 
additional constraint on single-key limits, namely  o / 2^k.  We won't 
fix a target advantage here.  Where we discuss the specific parameters 
in the example tables (Table 2 + 3, using a 2^-50 target for 
illustration), we'll explicitly add the offline work limits this entails.


The work factor approach is interesting. Given the goal of this draft is 
to provide simple guidance for AEAD users, esp. regarding how to limit 
key usage, I think the focus should be on the bounds incurred by 
encryption/decryption queries though. Ultimately, an AEAD user cannot do 
much about the o / 2^k part(s) of a bound for an AEAD scheme, except for 
selecting a scheme with different k.


> Orthogonally I have a philosophical question. [...] what incentive do 
> individual users have to use mu limits rather than single-user ones (su) 
> ones?

That's a nice philosophical question. Indeed, a single key ("user") 
might want to be selfish. The "user" of this document would however be, 
for example, a protocol designer. When defining a protocol standard, 
"unselfish" data limits are prescribed to limit the overall protocol 
attack surface. The origins of this draft are such data limits derived 
for TLS 1.3, DTLS 1.3, and QUIC. (Possibly this translates back to your 
analogy with speed limits; if so, in Germany we don't seem to have 
gotten the idea yet.)


On 2025-03-11 12:27 +0100, Daniel J. Bernstein <[e-mail]> wrote:
> Another reason not to ignore PRF terms is that there's a fast PRF attack
> against both AES-128 and AES-256 [...]  maybe all of the cited AES bounds
> are in the part of the literature that removes the issue by starting
> with PRP instead of PRF, but this is something to check carefully [...]

Indeed all the cited AES bounds start with PRP security.


> There are quite a few proofs cited in this draft, and I wonder how
> carefully they've been reviewed

If there are any concrete concerns/corrections regarding bounds in the 
proofs cited in this draft, we can integrate them.


Regards,
Felix