Limit fake contact event attacks by using shared hashed "handshake" about documents HOT 4 CLOSED

Publishing something else than private key of infected person is generally a good idea, I believe that EphIDs of ones at risk should be published instead, as in #14
But I see couple of problems with what you propose:

1. Number of published items and size of it (even if we use Bloom filter or anything else) grows significantly.
2. Encounter is not always a symmetric event. I can imagine multiple scenarios in which I've seen your RiD, but you haven't seen mine and the other way around.
3. How does it limit fake contact events attacks? I can still spoof any number of made-up encounters only if I know some RiDs. I see no much benefit of doing it compared to publishing EphIDs of those infected person encountered.

from documents.

Thanks for #14.

1. Yes. Perhaps you can't download it all anymore. You square the amount of data I guess.
2. I think enforcing symmetry brings a benefit: That would limit large scale fake contact event attacks based on Bluetooth amplifier able to reach a much higher radius.
3. You can not prevent it. But this limit one kind of attack (2).

from documents.

Thanks for suggesting this. We have considered this design internally, and it is currently not in our proposal because of the increased bandwidth consumption that it would entail. We continue to hold it on our list of possible-but-not-adopted approaches.

from documents.

What kind of bandwidth consumption are we talking about?

Are we sure we need to download all the data for every client?

from documents.