adding differential privacy to FixedPointBoundedL2VecSum #578

ooovi · 2023-05-18T12:51:46Z

As announced in #440, we added a feature for our fixed point vector type to add discrete gaussian noise to the aggregation result.

Changes to prio code that is not part of our type, currently all hidden behind the experimental feature flag:

The Type trait got an add_noise function that's the identity unless overridden.
The Aggregator trait got a postprocess function that's the identity unless overridden. The Aggregator implementation for Prio3 overrides it calling the add_noise function
There's an FlpError for errors happening during noising.

Our type overrides the default implementation of add_noise, and adds noise obtained using our sampler implementation.

Looking forward to your comments! :)

Co-Authored-By: Olivia ovi@posteo.de
Co-Authored-By: Maxim Urschumzew u.maxim@live.de

The relevant pull request is here: divviup/libprio-rs#578.

This comprises of the following changes: - Add a `noise_param` parameter to the fixedvec type(s) in the various vdaf enums. This describes the amount of noise to be added. - Wire up the new `postprocess()` function of prio to be called in both leader and helper. The noising itself happens in the implementation of the fixedvec type in prio, see the relevant pr (divviup/libprio-rs#578).

This comprises the following changes: - Add a `noise_param` parameter to the fixedvec type(s) in the various vdaf enums. This describes the amount of noise to be added. - Wire up the new `postprocess()` function of prio to be called in both leader and helper. The noising itself happens in the implementation of the fixedvec type in prio, see the relevant pr (divviup/libprio-rs#578).

cjpatton

Some high level comments to start! By the way I agree with the assessment that some sort of posprocessing step is needed, since in both DAP implementations (Janus/Daphne) aggregate() is not used directly to aggregate things (an accumulator is used instead).

src/vdaf.rs

src/flp.rs

src/flp/types/fixedpoint_l2/noise.rs

src/vdaf/prio3.rs

src/flp/types/fixedpoint_l2.rs

src/flp.rs

src/vdaf/prio3.rs

src/flp.rs

src/flp/types/fixedpoint_l2.rs

src/vdaf.rs

src/flp/types/fixedpoint_l2/noise.rs

MxmUrw · 2023-06-13T22:08:33Z

I think Tim's proposal of moving the parameter for differential privacy into an associated type on Aggregator is quite sensible, in particular since currently we have to use our zero_privacy_parameter() to pass a dummy (or default) parameter to a new vdaf instance in places where there is no notion of noising, such as most tests or the initialization of Client.

I have gone ahead and updated the code as suggested, applying some of the renaming-suggestions as well (ad81ed5).

cjpatton

Hey @ooovi, @MxmUrw: We met to discuss this PR today and decided that merging the discrete Gaussian stuff is the best option. (See inline comments.) The main concern right now is getting the API changes right. At a high level our requirements are:

Decouple the primitives from the VDAF implementation. Eventually what we would like to see is a module containing a variety of primitives suitable for building different DP mechanisms (client-side, server-side, usw.).
Make the primitives as generic as possible. Ideally the Gaussian sampler would take as input the $\epsilon$, $\delta$, sensitivity, and whatever other parameters are required and output a vector that can be added to an aggregate share. The same primitive should be useful for any VDAF for which it is compatible.
Ideally it would be possible for a user to use any DP mechanism they want (or none at all), so long as it's compatible with the given VDAF. Right now Prio3FixedPointBoundedL2VecSum can only be used with one DP mechanism (central-DP w/ discrete Gaussian).

I think the next thing to do is figure out the API changes for VDAF, in a separate PR. We sketched something in our meeting today and we plan to put up a PR soon. Would you please take a look when it's ready? Once it's merged, we can rebase this PR on top of it. Does that sound like a plan?

src/flp/types/fixedpoint_l2/noise.rs

src/flp.rs

src/flp/types/fixedpoint_l2.rs

src/flp/types/fixedpoint_l2/noise.rs

MxmUrw · 2023-07-04T10:41:17Z

Hi, we are wondering about what the best way for dealing with randomness seeds is:

We want the add_noise_to_agg_share function for our FixedPointBoundedL2VecSum type to be deterministic, in order to allow for testing.

There are multiple options:

Write a local deterministic function (let's call it f) which takes an rng: Rng and does what add_noise_to_agg_share should do. Then in the actual implementation of add_noise_to_agg_share use system randomness to create rng: Rng and pass it to f.
Add an rng: Rng argument to the add_noise_to_agg_share in AggregatorWithNoise. Then janus is responsible for passing in a seed.
Leave the AggregatorWithNoise trait as is, but add an rng: Rng argument to the add_noise_to_agg_share in TypeWithNoise. (This options seems strange in so far as it is unclear why Prio3 should be responsible for creating the rng)

divergentdave · 2023-07-05T15:33:57Z

Hi, we are wondering about what the best way for dealing with randomness seeds is:

We want the add_noise_to_agg_share function for our FixedPointBoundedL2VecSum type to be deterministic, in order to allow for testing.

There are multiple options:

1. Write a local deterministic function (let's call it `f`) which takes an `rng: Rng` and does what `add_noise_to_agg_share` should do. Then in the actual implementation of `add_noise_to_agg_share` use system randomness to create `rng: Rng` and pass it to `f`.

2. Add an `rng: Rng` argument to the `add_noise_to_agg_share` in `AggregatorWithNoise`. Then janus is responsible for passing in a seed.

3. Leave the `AggregatorWithNoise` trait as is, but add an `rng: Rng` argument to the `add_noise_to_agg_share` in `TypeWithNoise`. (This options seems strange in so far as it is unclear why `Prio3` should be responsible for creating the `rng`)

The first option sounds good, we do effectively the same thing for sharding, except passing in seeds themselves.

MxmUrw · 2023-07-05T15:55:20Z

Hello again, we have rebased our PR, and are ready to discuss!

There are quite a few changes, so here is a summary:

The DifferentialPrivacyStrategy trait now contains associated types for the type of budget, type of distribution and type of sensitivity. It furthermore requires from_budget() and create_distribution() methods. This might be controversial, see below for a further elaboration wrt. the previous discussion.
We imported the rational type Ratio<> from num_rational. This makes the implementation of the sampler more readable and closer to the reference implementation by hiding arithmetic with fractions. Furthermore, it is only used internally, so concerns regarding exposing this in the public interface of prio should not apply.
We now use Ratio<BigUInt> for the epsilon parameter in ZCdpBudget. The field is not public, instead a constructor taking the custom Rational type is provided. Additionally we provide a constructor accepting f32 values. Concerns regarding imprecision of this conversion (either because of privacy considerations or the need for test-vectors) should not apply, since the immediate internal conversion from f32 to Ratio<BigUint> can be done losslessly. (It might fail, however, since budgets are not allowed to be negative.)
We use Ratio<BigUint> for the sensitivity of ZCdpDiscreteGaussian strategy. The reason for using BigUints is that the sensitivity of our type is, depending on configuration, up to $2^{64}$ and thus does not fit into u32. We consider this to not be part of the public interface, as this value is going to be created inside the VDAF's AggregatorWithNoise implementation, and not by the user. Using BigUints is the most future-proof solution. On the other hand, one might argue that the sensitivity is in fact public; this highly depends on the definition of the DifferentialPrivacyStrategy trait. In such a case, one might want to use Rational (but with u128 values) instead.
We implemented the rand::RngCore and rand::SeedableRng traits for SeedStreamSha3. Someone should definitely look over that and check if we did it right.

Concerning (1):

I think that the main concern of @divergentdave was that at the time the additional type parameters of the trait would become infective for all occurrences of that trait. Instead of type parameters, we use associated types now, which alleviates this issue.
The main advantage of actually encoding the interface of a "dp strategy", instead of having an empty marker trait, is that code can be written generically in places where it makes sense to do so. It also serves as an implementation pattern, guiding the implementation of new strategies.
Another concern was that the proposed interface might not be general enough for instances where e.g. two different gaussian distributions are required in a VDAF, for example noising sums and squares of inputs separately. I claim that now the interface covers this use case, and I believe that it now covers a very broad range of use cases. This is arguably up to discussion.
To illustrate the previous point, I have implemented such a "double gaussian strategy" in the dp/experimental_strategy.rs. In fact, the current version of the trait allowed me to implement a generic ProductDpStrategy combinator which combines two arbitrary strategies into a new one. Such a combinator might be of interest by itself. The "double gaussian strategy" is simply an instance of applying this combinator to two ZCdpDiscreteGaussian strategies.
The dp/experimental_strategy.rs file is not necessarily intended as part of this PR, it exists mostly as an input for this discussion.
On a further note though, the current definition of this trait means that setting type Sensitivity = Ratio<BigUint> for ZCdpDiscreteGaussian could be interpreted as exposing the BigUint type to the public interface. The user does not have to deal with this, because he is not expected to call the create_distribution() method, which takes a Sensitivity argument, by himself. I do agree that this state of affairs might not be ideal. Possible solutions are:
1. Remove the expressiveness of the DifferentialPrivacyStrategy trait, reverting it to the pure marker trait which it was in API changes for Aggregator-side differential privacy #607.
2. Use URational<u128> for the sensitivity as noted in (5.).
3. Reintroduce a further market trait which is intended for the public interface, while keeping this trait to be used internally.

EDIT: Would reviewing be easier if we closed this, and opened a new PR?

cjpatton

How do the various DP traits relate to one another? It might be useful to put together little diagram and an explanation of it in the module documentation for dp.
I'm not sure that the implementation of add_noise_to_agg_share for FixedPointBoundedL2VecSum is correct, but I might be misunderstanding the code.
Regarding experimental_strategy module: What exactly is this demonstrating? In other words, could the use case that @divergentdave mentions be addressed differently?

src/dp.rs

src/flp.rs

src/dp/distributions.rs

@divergentdave

This was suggested by @divergentdave here: divviup#578 (comment) Also renaming `Type::add_noise_to_aggregate_share` to `add_noise_to_result`.

MxmUrw · 2023-07-13T15:41:59Z

How do the various DP traits relate to one another?

The general architecture comes from #607, there are three traits:

DifferentialPrivacyBudget: Implementors should be types of budgets for DP-mechanisms. Examples: zCDP, ApproximateDP (Epsilon-Delta), PureDP
DifferentialPrivacyDistribution: Distribution from which noise is sampled. Examples: DiscreteGaussian, DiscreteLaplace
DifferentialPrivacyStrategy: This is a combination of choices for budget and distribution. Examples: zCDP-DiscreteGaussian, EpsilonDelta-DiscreteGaussian

Directly, the public interface only mentions the strategy. Originally in @tholop's PR, all three were pure marker traits (didn't require anything for implementation). I am of the opinion that it would be useful to actually axiomatize what a "strategy" is (i.e. require references to the distribution and budget, as well as methods connecting them).

It might be useful to put together little diagram and an explanation of it in the module documentation for dp.

Sure, though I would prefer to do so when it is clear whether my proposal is going to be adopted (and with which changes), or we revert back to the previous state.

Regarding experimental_strategy module: What exactly is this demonstrating? In other words, could the use case that @divergentdave mentions be addressed differently?

Yes of course it could! The goal of my idea is that common patterns, i.e., the idea of what a "strategy" is, to be actually encoded in the trait interface. It is possible to skip this, and implement the noising for every Prio3 type individually for every strategy which it intends to support. The cost of code duplication probably wouldn't even be too much, as there is not too much infrastructural moving around of data happening.

My opinion is that all invariants and expectations of behaviour for a given set of objects (in this case implementors of a trait), which can be encoded statically in the type system, should be. In the sense of "code is the best documentation", as it can be checked by the compiler.

Thus what the experimental_strategy shows is that, assuming we make the Strategy trait as explicit as it currently is, that then the one thing which @divergentdave doubted would be possible, is still possible. In case you don't operate on the same assumption as stated above in italic, my addition probably does not have advantages besides making slightly more generic code possible. I could make an example which shows how generic noising for the simpler prio types could be implemented with my version of the trait.

I'm not sure that the implementation of add_noise_to_agg_share for FixedPointBoundedL2VecSum is correct, but I might be misunderstanding the code.

Do you have specific pointers why these doubts come up?

cjpatton

How do the various DP traits relate to one another?

The general architecture comes from #607, there are three traits:
* `DifferentialPrivacyBudget`: Implementors should be types of budgets for DP-mechanisms. Examples: zCDP, ApproximateDP (Epsilon-Delta), PureDP

* `DifferentialPrivacyDistribution`: Distribution from which noise is sampled. Examples: DiscreteGaussian, DiscreteLaplace

* `DifferentialPrivacyStrategy`: This is a combination of choices for budget _and_ distribution. Examples: zCDP-DiscreteGaussian, EpsilonDelta-DiscreteGaussian
Directly, the public interface only mentions the strategy. Originally in @tholop's PR, all three were pure marker traits (didn't require anything for implementation). I am of the opinion that it would be useful to actually axiomatize what a "strategy" is (i.e. require references to the distribution and budget, as well as methods connecting them).

That works for me. I would just dump this explanation in the dp module's docucomment.

Quick question: If DifferentialPrivacyStrategy actually needed? From your description it sounds like its functionality is already implied by a choice of DifferentialPrivacyBudget and DifferentialPrivacyDistribution. I'm sure I'm missing something obvious ...

It might be useful to put together little diagram and an explanation of it in the module documentation for dp.

Sure, though I would prefer to do so when it is clear whether my proposal is going to be adopted (and with which changes), or we revert back to the previous state.

Ack.

Regarding experimental_strategy module: What exactly is this demonstrating? In other words, could the use case that @divergentdave mentions be addressed differently?

Yes of course it could! The goal of my idea is that common patterns, i.e., the idea of what a "strategy" is, to be actually encoded in the trait interface. It is possible to skip this, and implement the noising for every Prio3 type individually for every strategy which it intends to support. The cost of code duplication probably wouldn't even be too much, as there is not too much infrastructural moving around of data happening.

My opinion is that all invariants and expectations of behaviour for a given set of objects (in this case implementors of a trait), which can be encoded statically in the type system, should be. In the sense of "code is the best documentation", as it can be checked by the compiler.

I agree in principle, but from practical experience there is a degree to which adding too many trait bounds becomes cumbersome. Either way I think we're in a good place with the traits we already have (Budget, Distribution, Strategy (although see my question above).

Thus what the experimental_strategy shows is that, assuming we make the Strategy trait as explicit as it currently is, that then the one thing which @divergentdave doubted would be possible, is still possible. In case you don't operate on the same assumption as stated above in italic, my addition probably does not have advantages besides making slightly more generic code possible. I could make an example which shows how generic noising for the simpler prio types could be implemented with my version of the trait.

Sounds good. Unless we intend to use it for this PR, I think we should remove the experimental_strategy.rs module. Better to only check in code we intend to use!

I'm not sure that the implementation of add_noise_to_agg_share for FixedPointBoundedL2VecSum is correct, but I might be misunderstanding the code.

Do you have specific pointers why these doubts come up?

I've already commented in-line but it seems that they've gotten lost somehow. I'll follow up.

src/dp/distributions.rs

src/vdaf/prg.rs

tholop

I only reviewed distribution.rs. My biggest worry is that the OpenDP implementation doesn't follow the CKS20 pseudocode line-by-line, so it's hard to assess its correctness. I left some comments for parts that I don't understand.

src/dp/distributions.rs

src/dp.rs

MxmUrw · 2023-07-13T16:36:37Z

Quick question: If DifferentialPrivacyStrategy actually needed? From your description it sounds like its functionality is already implied by a choice of DifferentialPrivacyBudget and DifferentialPrivacyDistribution. I'm sure I'm missing something obvious ...

The DifferentialPrivacyStrategy trait actually allows us to tackle the "too many trait bounds" problem: in the AggregatorWithNoise trait, only this trait is mentioned, thus reducing the number of trait bounds from 2 to 1. Additionally, it houses the logic which expresses how a privacy budget can be turned into a distribution.

Unless we intend to use it for this PR, I think we should remove the experimental_strategy.rs module. Better to only check in code we intend to use!

I agree. Once the design is accepted, I'll remove it. I'm kind of waiting for @divergentdave's opinion.

MxmUrw · 2023-08-22T09:47:38Z

I think there might be an issue with the caching of cargo vet? Locally cargo vet --locked succeeds...

divergentdave · 2023-08-22T11:21:31Z

The new exemptions and num-iter imported audit were removed by PR #688, (because of running cargo vet prune on that branch) so the merge commit that CI is run against is missing exemptions, even though your branch isn't. I think you'll need to rebase, add the exemptions back to supply-chain/config.toml, and run cargo vet to pull in the import again.

Co-Authored-By: Olivia <ovi@posteo.de> Co-Authored-By: Maxim Urschumzew <u.maxim@live.de>

MxmUrw · 2023-08-23T19:07:32Z

I think you'll need to rebase, add the exemptions back to supply-chain/config.toml, and run cargo vet to pull in the import again.

Thanks, I did, and I also ran cargo vet prune because it asked me to.

And, we're green!

Co-Authored-By: Olivia <ovi@posteo.de> Co-Authored-By: Maxim Urschumzew <u.maxim@live.de>

MxmUrw · 2023-08-25T13:43:26Z

@divergentdave, I was a little bit unsure about the rebase onto 87d4a65, it looks like this now:

#[cfg(all(feature = "prio2", feature = "experimental"))]
criterion_group!(benches, poplar1, prio3, prio2, poly_mul, prng, idpf, dp_noise);
#[cfg(all(not(feature = "prio2"), feature = "experimental"))]
criterion_group!(benches, poplar1, prio3, poly_mul, prng, idpf, dp_noise);
#[cfg(all(feature = "prio2", not(feature = "experimental")))]
criterion_group!(benches, prio3, prio2, prng, poly_mul);
#[cfg(all(not(feature = "prio2"), not(feature = "experimental")))]
criterion_group!(benches, prio3, prng, poly_mul);

MxmUrw · 2023-08-25T16:27:33Z

@cjpatton , @tgeoghegan is there something left we need to do to get this merged?

tgeoghegan · 2023-08-25T21:07:04Z

If Chris and David are happy with the change, then I think we can take it.

cjpatton · 2023-08-25T21:13:45Z

@tgeoghegan I just wanted to flag #578 (review) in case you wanted to double check that the licensing is good to go.

divergentdave · 2023-08-25T21:31:31Z

We discussed the licensing internally and we're satisfied with it; merging now.

commit 3d5f759 Author: ovi <ovi@posteo.de> Date: Fri Sep 8 17:57:46 2023 +0200 ordering ZCdpBudget commit d6a9985 Author: ovi <ovi@posteo.de> Date: Fri Sep 8 17:53:18 2023 +0200 ordering ZCdpDiscreteGaussians commit d2cdd4c Author: ovi <ovi@posteo.de> Date: Mon Sep 4 16:17:38 2023 +0200 non-pub epsilon commit cfef6a7 Author: ovi <ovi@posteo.de> Date: Mon Sep 4 15:07:01 2023 +0200 pub budget commit eae7e4e Author: ovi <ovi@posteo.de> Date: Mon Sep 4 14:32:57 2023 +0200 Display for error commit 410427e Author: ovi <ovi@posteo.de> Date: Mon Sep 4 13:53:37 2023 +0200 FromStr for Rational commit 59f5522 Author: ovi <ovi@posteo.de> Date: Sun Sep 3 14:13:20 2023 +0200 Display Rational commit 3ac128d Author: ovi <ovi@posteo.de> Date: Sun Sep 3 13:11:47 2023 +0200 trying a thing commit 42e6cad Author: ovi <ovi@posteo.de> Date: Sat Sep 2 03:07:45 2023 +0200 yet more derives commit d43961a Author: ovi <ovi@posteo.de> Date: Sat Sep 2 01:39:16 2023 +0200 yet more derives commit 76d20d9 Author: Maxim Urschumzew <u.maxim@live.de> Date: Thu Aug 31 08:59:19 2023 +0200 Add more derives. commit 7bced48 Author: Maxim Urschumzew <u.maxim@live.de> Date: Thu Aug 31 08:53:04 2023 +0200 Add derive. commit fcdc568 Author: Maxim Urschumzew <u.maxim@live.de> Date: Tue Aug 29 11:51:53 2023 +0200 Add serialize for rational. commit bd41119 Author: Maxim Urschumzew <u.maxim@live.de> Date: Sun Aug 27 18:25:33 2023 +0200 Add default impl for poplar. commit 2437364 Author: Maxim Urschumzew <u.maxim@live.de> Date: Sun Aug 27 18:21:15 2023 +0200 Add default implementations. commit 7c45460 Author: Maxim Urschumzew <u.maxim@live.de> Date: Sun Aug 27 17:47:41 2023 +0200 Add default implementation for `TypeWithNoise`. commit e5bdff3 Author: Maxim Urschumzew <u.maxim@live.de> Date: Mon Aug 14 13:34:03 2023 +0200 Add differential privacy to `FixedPointBoundedL2VecSum` (divviup#578). Co-Authored-By: Olivia <ovi@posteo.de> Co-Authored-By: Maxim Urschumzew <u.maxim@live.de>

ooovi requested a review from a team as a code owner May 18, 2023 12:51

tgeoghegan requested a review from cjpatton May 18, 2023 16:08

MxmUrw added a commit to dpsa4fl/janus that referenced this pull request May 19, 2023

Update to use the prio fork with fixedvec dp noise.

f08a7e5

The relevant pull request is here: divviup/libprio-rs#578.

MxmUrw added a commit to dpsa4fl/janus that referenced this pull request May 30, 2023

Update to use the prio fork with fixedvec dp noise.

f137dce

The relevant pull request is here: divviup/libprio-rs#578.

MxmUrw mentioned this pull request Jun 2, 2023

Enable differential privacy for FixedPointBoundedL2VecSum. divviup/janus#1440

Closed

1 task

cjpatton reviewed Jun 7, 2023

View reviewed changes

tgeoghegan reviewed Jun 9, 2023

View reviewed changes

cjpatton reviewed Jun 16, 2023

View reviewed changes

tholop mentioned this pull request Jun 16, 2023

API changes for Aggregator-side differential privacy #607

Merged

MxmUrw force-pushed the feature-fixedvec-dp branch from 2e21f75 to fa92453 Compare June 30, 2023 11:29

tholop reviewed Jun 30, 2023

View reviewed changes

src/flp/types/fixedpoint_l2/noise.rs Outdated Show resolved Hide resolved

ooovi force-pushed the feature-fixedvec-dp branch from 1073d8f to 4a3951d Compare July 1, 2023 13:25

ooovi requested review from divergentdave, MxmUrw, cjpatton, tgeoghegan and tholop July 10, 2023 09:08

cjpatton reviewed Jul 11, 2023

View reviewed changes

cjpatton reviewed Jul 13, 2023

View reviewed changes

src/dp/distributions.rs Outdated Show resolved Hide resolved

src/vdaf/prg.rs Outdated Show resolved Hide resolved

src/vdaf/prg.rs Outdated Show resolved Hide resolved

tholop reviewed Jul 13, 2023

View reviewed changes

ooovi mentioned this pull request Aug 22, 2023

Support exactly adding differential privacy to functions with square root irrational sensitivity #694

Open

MxmUrw added a commit to dpsa4fl/libprio-rs that referenced this pull request Aug 23, 2023

Add differential privacy to FixedPointBoundedL2VecSum (divviup#578).

29067d9

Co-Authored-By: Olivia <ovi@posteo.de> Co-Authored-By: Maxim Urschumzew <u.maxim@live.de>

MxmUrw force-pushed the feature-fixedvec-dp branch from dd50c94 to 29067d9 Compare August 23, 2023 18:20

MxmUrw added a commit to dpsa4fl/libprio-rs that referenced this pull request Aug 23, 2023

Add differential privacy to FixedPointBoundedL2VecSum (divviup#578).

e34885b

Co-Authored-By: Olivia <ovi@posteo.de> Co-Authored-By: Maxim Urschumzew <u.maxim@live.de>

MxmUrw force-pushed the feature-fixedvec-dp branch from 29067d9 to e34885b Compare August 23, 2023 18:34

divergentdave approved these changes Aug 23, 2023

View reviewed changes

MxmUrw added a commit to dpsa4fl/libprio-rs that referenced this pull request Aug 25, 2023

Add differential privacy to FixedPointBoundedL2VecSum (divviup#578).

fb5363b

Co-Authored-By: Olivia <ovi@posteo.de> Co-Authored-By: Maxim Urschumzew <u.maxim@live.de>

MxmUrw force-pushed the feature-fixedvec-dp branch from e34885b to fb5363b Compare August 25, 2023 12:28

MxmUrw added a commit to dpsa4fl/libprio-rs that referenced this pull request Aug 25, 2023

Add differential privacy to FixedPointBoundedL2VecSum (divviup#578).

81306a0

Co-Authored-By: Olivia <ovi@posteo.de> Co-Authored-By: Maxim Urschumzew <u.maxim@live.de>

MxmUrw force-pushed the feature-fixedvec-dp branch from fb5363b to 81306a0 Compare August 25, 2023 12:30

MxmUrw added a commit to dpsa4fl/libprio-rs that referenced this pull request Aug 25, 2023

Add differential privacy to FixedPointBoundedL2VecSum (divviup#578).

3d0c502

Co-Authored-By: Olivia <ovi@posteo.de> Co-Authored-By: Maxim Urschumzew <u.maxim@live.de>

MxmUrw force-pushed the feature-fixedvec-dp branch from 81306a0 to 3d0c502 Compare August 25, 2023 12:30

Add differential privacy to FixedPointBoundedL2VecSum (divviup#578).

e5bdff3

Co-Authored-By: Olivia <ovi@posteo.de> Co-Authored-By: Maxim Urschumzew <u.maxim@live.de>

MxmUrw force-pushed the feature-fixedvec-dp branch from 3d0c502 to e5bdff3 Compare August 25, 2023 12:40

divergentdave merged commit 92f9ae5 into divviup:main Aug 25, 2023

divergentdave mentioned this pull request Aug 25, 2023

Clean up statest dependency #708

Merged

MxmUrw deleted the feature-fixedvec-dp branch August 26, 2023 17:05

MxmUrw mentioned this pull request Aug 31, 2023

Discussion: How to integrate differential privacy into janus? divviup/janus#1865

Closed

ooovi mentioned this pull request Mar 6, 2024

Discrete Gaussian distribution in rand_distr? rust-random/rand_distr#6

Open

divergentdave mentioned this pull request Jun 6, 2024

Add support for DP noise during aggregation for Prio3SumVec, Prio3Histogram #1072

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

adding differential privacy to FixedPointBoundedL2VecSum #578

adding differential privacy to FixedPointBoundedL2VecSum #578

ooovi commented May 18, 2023

cjpatton left a comment

MxmUrw commented Jun 13, 2023

cjpatton left a comment

MxmUrw commented Jul 4, 2023

divergentdave commented Jul 5, 2023

MxmUrw commented Jul 5, 2023 •

edited

Loading

cjpatton left a comment

MxmUrw commented Jul 13, 2023 •

edited

Loading

cjpatton left a comment

tholop left a comment

MxmUrw commented Jul 13, 2023

MxmUrw commented Aug 22, 2023

divergentdave commented Aug 22, 2023

MxmUrw commented Aug 23, 2023

MxmUrw commented Aug 25, 2023

MxmUrw commented Aug 25, 2023

tgeoghegan commented Aug 25, 2023

cjpatton commented Aug 25, 2023

divergentdave commented Aug 25, 2023

adding differential privacy to FixedPointBoundedL2VecSum #578

adding differential privacy to FixedPointBoundedL2VecSum #578

Conversation

ooovi commented May 18, 2023

cjpatton left a comment

Choose a reason for hiding this comment

MxmUrw commented Jun 13, 2023

cjpatton left a comment

Choose a reason for hiding this comment

MxmUrw commented Jul 4, 2023

divergentdave commented Jul 5, 2023

MxmUrw commented Jul 5, 2023 • edited Loading

cjpatton left a comment

Choose a reason for hiding this comment

MxmUrw commented Jul 13, 2023 • edited Loading

cjpatton left a comment

Choose a reason for hiding this comment

tholop left a comment

Choose a reason for hiding this comment

MxmUrw commented Jul 13, 2023

MxmUrw commented Aug 22, 2023

divergentdave commented Aug 22, 2023

MxmUrw commented Aug 23, 2023

MxmUrw commented Aug 25, 2023

MxmUrw commented Aug 25, 2023

tgeoghegan commented Aug 25, 2023

cjpatton commented Aug 25, 2023

divergentdave commented Aug 25, 2023

MxmUrw commented Jul 5, 2023 •

edited

Loading

MxmUrw commented Jul 13, 2023 •

edited

Loading