From bb01e528dab1da66c3264347a7c020f2c3403494 Mon Sep 17 00:00:00 2001 From: Christopher Patton Date: Fri, 6 Sep 2024 15:09:36 -0700 Subject: [PATCH] Add defenses-in-depth section Note defenses against cross protocol attacks resulting from weak entropy or weak parameters. Also, acknowledge the possibility of cross protocol attacks within a circuit family (no binding of the circuit parameters) and the blast radius of weak parameters (all deployed tasks). Co-authored-by: David Cook --- draft-irtf-cfrg-vdaf.md | 51 +++++++++++++++++++++++++++++++++++------ 1 file changed, 44 insertions(+), 7 deletions(-) diff --git a/draft-irtf-cfrg-vdaf.md b/draft-irtf-cfrg-vdaf.md index 494591a3..7d5b0dfe 100644 --- a/draft-irtf-cfrg-vdaf.md +++ b/draft-irtf-cfrg-vdaf.md @@ -2126,8 +2126,8 @@ cases where a more efficient instantiation based on fixed-key AES is possible. For now, this is limited to the XOF used inside the Idpf {{idpf}} implementation in Poplar1 {{idpf-bbcggi21}}. It is NOT RECOMMENDED to use this XOF anywhere else. The length of the domain separation string `dst` passed to -XofFixedKeyAes128 MUST NOT exceed 255 bytes. See Security Considerations -{{security}} for a more detailed discussion. +XofFixedKeyAes128 MUST NOT exceed 255 bytes. See {{security}} for a more +detailed discussion. ~~~ python class XofFixedKeyAes128(Xof): @@ -5530,11 +5530,14 @@ Care must be taken, however, since a smaller field also results in degraded (or even vacuous) robustness. Different variants of Prio3 ({{prio3}}) use different field sizes: Prio3Count -uses Field64; but Prio3Sum, Prio3SumVec, and Prio3Histogram use Field128, a -field that is twice as large as Field64. This is due to the use of joint -randomness ({{flp}}) in the latter variants. Joint randomness allows for more -flexible circuit design (see {{flp-bbcggi19-overview-extensions}}), but opens up -Prio3 to precomputation attacks, which the larger field mitigates. (See +and Prio3Sum use Field64; but Prio3SumVec, Prio3Histogram, and +Prio3MultihotCountVec all use Field128, a field that is twice as large as +Field64. This is due to the use of joint randomness ({{flp}}) in the latter +variants. Joint randomness allows for more flexible circuit design (see +{{flp-bbcggi19-overview-extensions}}), but opens up Prio3 to offline attacks in +which the attacker searches for input shares for an invalid measurement that +derive joint randomness that causes the circuit to accept. Choosing a large +enough field ensures this computation is too expensive to be feasible. (See {{DPRS23}}, Theorem 1.) Note that privacy is not susceptible to such attacks. Another way to mitigate this issue (or improve robustness in general) is to @@ -5548,6 +5551,11 @@ instead, but `PROOFS` MUST be set to at least `3`. Breaking robustness for `PROOFS == 2` is feasible, if impractical; but `PROOFS == 1` is completely broken for such a small field. +We stress that weak parameters (too small a field, too few proofs, or both) can +be exploited to attack any aggregation task using those parameters. To +mitigate offline attacks, it is necessary to disable all tasks that use the +weak parameters. + ## Choosing the Number of Aggregators {#num-aggregators} Two Aggregators are required for privacy in our threat model, but some (V)DAFs, @@ -5558,6 +5566,35 @@ may consider involving more than two Aggregators as described for example in {{star-topo}}. Note however that some schemes are not compatible with this mode of operation, such as Poplar1. +## Defense-in-Depth Measures + +Prio3 and Poplar1 are designed to resist some attacks that fall outside the +main threat model for VDAFs. + +Broadly speaking, domain separation is used to prevent cross protocol attacks, +in which data from evaluation of one VDAF translates to an attack against another. +For example: + +1. Weak entropy sources: the VDAF algorithm ID is bound to each XOF invocation, + thereby ensuring the outputs are different between VDAF invocations, even if + the underlying randomness is the same. For example, two different instances + of Prio3 would compute different measurement shares. + +1. Weak parameters: Prio3 variants that require joint randomness are subject to + offline attacks against robustness. These attacks are feasible if the field + size or number of proofs is sufficiently small. (See + {{security-multiproof}}.) The joint randomness derivation is bound to both + the field (via the algorithm ID) and the number of proofs, thereby ensuring + that joint randomness derived for weak parameters is not reused for stronger + parameters. + +There are also some important limitations to be aware of. For example, Prio3 +provides domain separation between families of circuits, but does not provide +domain separation between instances of a circuit. Concretely, it is possible +for Aggregators to accept a report for Prio3SumVec from a Client who disagrees +with them on the value of `bits` and `length`. This is because there is no +binding of the circuit parameters to the computation. + # IANA Considerations IANA is requested to make one new registry: