parent
dca0792928
commit
c5a96de77d
@ 0,0 +1,14 @@


# Intersection Attacks




One of the most basic attacks primitives for any kind of false positive based scheme is an intersection attack, where


the set of peers that match one tag is intersected against another set of peets that matches a different tag.




Any kind of intersection attacks break this scheme, even for a small number of messages i.e. if you learn (through


any means) that a specific set of messages are all likely for a single party, you can diff them against all other parties keys and


very quickly isolate the intended recipient  in simulations of 1001000 parties it can take as little as 3 messages  even


with everyone selecting fairly high false positive rates.




The corollary of the above being that in intersection attacks your anonymity set is the number of users


who download all messages. This has the interesting side effect: the more parties who download everything,


the more the system can safely tolerate parties with small falsepositive rates.



@ 0,0 +1,11 @@


# Risk Model




In this section we will document the risk model and attacks that will likely impact practical deployments


of fuzzytags.




We assume a set of $n$ parties sending tags and messages through an untrusted server.




For some of the analysis in this notebook we will assume that the server has knowledge of the sender of each tag.




While this is not desirable in realworld deployments, being able to match tags to senders does allow us to derive


bounds on worst case metadata leakage.

@ 0,0 +1,22 @@


# Statistical Attacks




Using some basic binomial probability we can use the false positive rate of reach receiver tag to calculate


the probability of matching on at least X tags given the false positive rate. Using this we can find statistically


unlikely matches e.g. a lowfalse positive key matching many tags in a given period.




This can be used to find receivers who likely received messages in a given period. This attack works regardless


of how many parties are downloading everything, and is entirely dependent on the receiver choosing $p$ that is


suboptimal for the number of messages they receive.




## Deriving the Social Graph




If it is possible to group tags by sender then we can perform a slightly better attack and ultimately learn the


underlying social graph with fairly low false positive rates (in [simulations](./simulations.md) we can learn 510% of


the underlying connections with between 512% false positive rates.)




The method is the same as above, but look at the probability that a party would have matched at least X tags _from a


specific sender_ given their false positive rate.




Notably, this latter attack reveals something important about choosing parameters for fuzzytags  _p_ must be chosen


to take into account not just total number of messages, but total number of messages from a given source (or it


must be assumed that the server will never be able to isolate tags from a given sender)

Loading…
Reference in new issue