Skip to content

Commit

Permalink
Anonymize the comments
Browse files Browse the repository at this point in the history
  • Loading branch information
cjpatton committed Feb 6, 2024
1 parent fa28638 commit 7cdd184
Show file tree
Hide file tree
Showing 4 changed files with 16 additions and 17 deletions.
11 changes: 5 additions & 6 deletions src/bin/driver.rs
Original file line number Diff line number Diff line change
Expand Up @@ -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(),
Expand Down
10 changes: 5 additions & 5 deletions src/collect.rs
Original file line number Diff line number Diff line change
Expand Up @@ -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<Field128> {
let mut jr_parts = *self.report_shares[client_index]
.1
Expand Down
4 changes: 2 additions & 2 deletions src/prg.rs
Original file line number Diff line number Diff line change
Expand Up @@ -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));
Expand Down
8 changes: 4 additions & 4 deletions src/vidpf.rs
Original file line number Diff line number Diff line change
Expand Up @@ -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);
Expand Down

0 comments on commit 7cdd184

Please sign in to comment.