Insecure noise primitives should be marked as such and/or removed entirely

[TedTed]

Hi folks,

As you already know, the floating-point noise mechanisms provided by diffprivlib are all vulnerable to precision-based attacks, as described in this blog post or this paper. This also affects the Laplace and Gaussian primitives based on the EuroS&P '21 paper that unsuccessfully attempts to mitigate floating-point vulnerabilities by combining more samples.

I assumed this was broadly common knowledge by now, but I was wrong: a DP tool recently published by Oasis Labs ends up reusing the same method, falling vulnerable to the attack published 2 years ago. It would be nice to more proactively warn people so this kind of thing doesn't happen again. There are multiple ways this could be done.

• Removing insecure noise addition primitives altogether from diffprivlib, or replacing them with provably robust approaches.
• Clearly documenting that these primitives are insecure in their docstring.
• Documenting known vulnerabilities in a specific page of your documentation and/or on the README file.
• Retracting or otherwise annotating the EuroS&P paper to warn people about the vulnerability.
• Adding a note to arXiv and/or updating the paper itself to add this warning.

The first three suggestions could also apply to other issues, like the handling of NaN, infinity, or otherwise extremum values.

[naoise-h]

Hi @TedTed, thanks for raising the issue! We are currently in the final stages of preparing new work for publication that takes a new approach to this problem. We hope to be in a position to publish this in the near future. We're not satisifed that the current state of the art is fit for purpose for a number of reasons.

The defence presented in our ESORICS 2021 paper remains a valid defence to the Mironov attack, which is the more potent of the known floating-point attacks, and the only one known at the time of publication. Using this defence is still far better than doing nothing.

Diffprivlib is a research asset and not intended for production use cases, but has proven to be a valuable tool for fostering new research in DP (including the new class of floating-point attacks we're discussing here!) and in education. We will nonetheless keep this issue open in the meantime.

[TedTed]

Thanks @naoise-h. I'm looking forward to read about your new approach!

One follow-up question: do you intend to mention these vulnerabilities, and explicitly point out that diffprivlib should not be used for production use cases, somewhere in your documentation?

Right now, these insecure noise primitives claim to "prevent against reconstruction attacks due to limited floating point precision", while your README.md says that people can use diffprivlib to "build your own differential privacy applications".