From 7cdd18478bf132bbb471b9c8a9e227d6cd707002 Mon Sep 17 00:00:00 2001 From: Christopher Patton Date: Tue, 6 Feb 2024 14:28:45 -0800 Subject: [PATCH] Anonymize the comments --- src/bin/driver.rs | 11 +++++------ src/collect.rs | 10 +++++----- src/prg.rs | 4 ++-- src/vidpf.rs | 8 ++++---- 4 files changed, 16 insertions(+), 17 deletions(-) diff --git a/src/bin/driver.rs b/src/bin/driver.rs index 8e35cc7..8a5d462 100644 --- a/src/bin/driver.rs +++ b/src/bin/driver.rs @@ -640,12 +640,11 @@ async fn run_plain_metrics( // Relay each aggregator's prep shares to its peer. // - // NOTE(cjpatton) To validate the report, each aggregator combines the prep shares, - // then uses the combined prep message and its state to compute its output share. Thus - // it is necessary to relay each aggregator's prep share to its peer. We could save - // communication here by having the driver compute the prep message at this point, - // however the libprio-rs API currently doesn't allow this. See - // https://github.com/divviup/libprio-rs/issues/912. + // NOTE To validate the report, each aggregator combines the prep shares, then uses the + // combined prep message and its state to compute its output share. Thus it is necessary to + // relay each aggregator's prep share to its peer. We could save communication here by + // having the driver compute the prep message at this point, however the libprio-rs API + // currently doesn't allow this. See https://github.com/divviup/libprio-rs/issues/912. let t = Instant::now(); let resp_0 = client_0.plain_metrics_result( long_context(), diff --git a/src/collect.rs b/src/collect.rs index c17b5c3..b40597e 100644 --- a/src/collect.rs +++ b/src/collect.rs @@ -283,11 +283,11 @@ impl KeyCollection { /// Compute joint randomness for FLP evaluation. /// - /// NOTE(cjpatton) This does not match the spec and is not secure. In particular, a malicious - /// client can pick joint randomness that it knows the circuit will verify. Preventing this - /// requires a bit more computation and communication overhead: each aggregator is supposed to - /// derive the correct joint randomness part from its input share and send it to the other so - /// that they can check if the advertised parts were actually computed correctly. + /// NOTE This does not match the spec and is not secure. In particular, a malicious client can + /// pick joint randomness that it knows the circuit will verify. Preventing this requires a bit + /// more computation and communication overhead: each aggregator is supposed to derive the + /// correct joint randomness part from its input share and send it to the other so that they + /// can check if the advertised parts were actually computed correctly. pub fn flp_joint_rand(&self, client_index: usize) -> Vec { let mut jr_parts = *self.report_shares[client_index] .1 diff --git a/src/prg.rs b/src/prg.rs index c9cbc39..39fc1e7 100644 --- a/src/prg.rs +++ b/src/prg.rs @@ -307,8 +307,8 @@ impl FixedKeyPrgStream { } else { let Counter(mut block) = v; - // NOTE(cjpatton) This might produce a different counter than for x86_64. It - // depends on the endianness of _mm_set_epi64x, which I haven't checked. + // NOTE This might produce a different counter than for x86_64. It depends on the + // endianness of _mm_set_epi64x, which I haven't checked. let mut carry = true; for byte in block.as_mut_slice().iter_mut().take(8) { (*byte, carry) = (*byte).overflowing_add(u8::from(carry)); diff --git a/src/vidpf.rs b/src/vidpf.rs index dc88a72..791aeb8 100644 --- a/src/vidpf.rs +++ b/src/vidpf.rs @@ -428,10 +428,10 @@ impl VidpfKey { // Traverse each indicated path of the subtree, appending the path checks and onehot checks // to the evaluation proof. // - // NOTE(cjpatton) The order in which we traverse the tree and the computation of the - // evaluation proof differ from the draft. The onehot proofs in particular need careful - // consideration, as we don't daisy-chain them directly to compute a unified onehot proof - // fo the entire traversal. Instead we interleave the components with the path checks. + // NOTE The order in which we traverse the tree and the computation of the evaluation proof + // differ from the draft. The onehot proofs in particular need careful consideration, as we + // don't daisy-chain them directly to compute a unified onehot proof for the entire + // traversal. Instead we interleave the components with the path checks. for path in paths { assert_ne!(path.as_ref().len(), 0); let node = root.traverse(path.as_ref(), self, input_len, eval_proof);