-
Notifications
You must be signed in to change notification settings - Fork 180
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Infection reveals lots, so consider using cuckoo filters #24
Comments
I do not get why they want an infected user to share their sk_t with others. It should be only shared with the server to confirm that infected person is one it claims to be (proving ownership of given ephids). |
I'd assume they're concerned the ephids would be too numerous. |
@burdges And that is why ephids probably should be published in the form of some Bloom(-ish) filters as many has pointed out before. |
I briefly thought about that, but I did not notice any such issues, and did not work out the filter parameter space myself. We should close this issue in favor of whatever issue worked out the filter parameters. |
If your target false positive rate lies blow 3%, which it obviously does here, then cuckoo filters are more space efficient than bloom filters. As a quick guesstimate, we require about only a couple bytes per newly infected person in the daily cuckoo filter, so I think distributing this daily cuckoo filter sounds doable via libtorrent. I've renamed this issues because seemingly no existing discussions covered this. |
I honestly never heard before of Bloom or cuckoo filters, but can you help me understand how they mitigate #37? If the published infected info is neither the set of his EphIDs or the sk_t that generated them, but rather the Bloom/cuckoo filter for his set of EphIDs, can't malicious users just test all the EphIDs they tracked against the filter? |
@inaitana Cuckoo/Bloom filters are probabilistic data structures. They have a given (and adjustable) ratio of false-positives. And we would sacrifice some false-positives for a small privacy gain. Attacker can't be sure if the given EphID was in fact marked, or it is just a false-positive. |
Ok, but if the attackers built a significative history of EphIDs locations false positives wouldn't be much of a problem. Every person must have an EphID in every significative timeframe (a day, in the current proposed implementation) when tracing is desired to happen. This is required for the solution to work. Let's say you analyse 14 days traffic, and 16 EphIDs test positive against an infected person's filter. This implementation would just slightly mitigate the problem by adding some false locations for the infected person (which can be filtered out), but most of the person's location history, especially domicile and frequent locations, could still be pinpointed effectively. And this would be at the cost of creating false positive alarms for regular users. |
I'm considering the possibility to not publish EphIDs but let clients periodically query the backend for their EphIDs presence. Clients can query only for theirs EphID. This will permit to not publish any data, sk_t nor EphIDs at all. |
Incorrect @jasisz we do not improve privacy meaningfully from false positives. We improve location privacy for infected people dramatically by their ephids not being linked together. We'd batch all infections detected over a couple day period into one large cuckoo filter. Any private query scheme incurs significant privacy costs @camstork especially if you must query daily for all 20,000 ephids from a 2 week period (one fresh ephids one per minute). We prefer cryptographic or unbreakable location privacy for uninfected individuals, but a PIR-like query exposes their location if all servers collude. We've discussed SURB schemes on the mixnet repo, in which users "pre-query each ephid only once" by supplying a SURB, but mixnet schemes lie outside DP-3T. |
They've added why they discarded our propositions in FAQ: https://github.com/DP-3T/documents/blob/master/FAQ.md |
@burdges batching multiple infections into one filter would be a good idea and partially hinder consistently backtracing a single infected user's locations. |
You cannot "link ephids" created with a PRF for which the key remains secret. You can expose infected peoples' real identities under all proposed solutions though. |
I meant empirically linking them together by analyzing frequent locations. |
They've added it to the doc as an alternative design. |
We have added an alternative design in the new version of the whitepaper. The alternative design uses cuckoo filters, comments welcome! We documented the main trade-offs between the two designs. |
If I understand, an infected user reveals the linkage between all their ephids by revealing their sk_t. It's quite efficient solution, but revealing this linkage might discourage adoption and/or discourage disclosure. I'd think too few individuals worry about their privacy enough for this to be a serious problem.
There is however some risk that individuals might observe and publish ephids along with location information, which ties published sk_t to real movements. If done, this could harm adoption or increases disclosure refusals more than linkability concerns.
We could consider doing the hashing inside some trusted enclave, except iOS lacks this. If iOS proves unworkable for other reasons like #7 then this sounds more plausible.
Instead, I'd suggest merely giving user control over pausing and switching between sk chains whenever they like. I doubt devices could manage a few independent sk chains automatically, but appl forks could attempt to do this too.
The text was updated successfully, but these errors were encountered: