Re: [quicwg/base-drafts] Expand AEAD limits to consider multi-user security. (#3789)

[Martin Thomson <[e-mail]>]

@martinthomson commented on this pull request.



> @@ -2207,10 +2206,14 @@ v:
   bound on the number of forged packets that an endpoint can reject before
   updating keys.
 
-The analysis of AEAD_AES_128_CCM relies on a count of the number of block
-operations involved in producing each message. For simplicity, and to match the
-analysis of other AEAD functions in {{AEBounds}}, this analysis assumes a
-packet length of 2^10 blocks and a packet size limit of 2^14.
+o:
+
+: The amount of offline ideal cipher queries made by an adversary.
+
+The analyses that follow rely on a count of the number of block operations
+involved in producing each message. For simplicity, and to match the analysis of
+other AEAD functions in {{AEBounds}}, this analysis assumes a packet length of
+2^10 blocks; that is, a packet size limit of 2^14 bytes.

Line 1588 (on the new side).  David raised an issue requesting that we provide limits based on an assumption of 2^16 byte packets.  If we do that, we might want to do a split between 2^11 and 2^16 rather than having 2^14.  We should track that on that issue though.

> +
+~~~
+(q + v) <= 2^28
+~~~
+
+Assuming `v = q`, endpoints cannot protect more than 2^27 packets in a single
+connection without causing an attacker to gain an larger advantage than the
+target of 2^-60.
+
+### Integrity Limit
+
+For integrity, Theorem (4.3) in {{?GCM-MU}} establishes that an attacker gains
+an advantage in successfully forging a packet of no more than:
+
+~~~
+(1 / 2^(8 * n)) + ((2 * v) / 2^2*n) + ((2 * o * v) / 2^(k + n))

OK, that's safe (just).

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/3789#discussion_r445933209