3 ms·
Some paper reading shows that while interesting, the technique being used has issues with churn. This means small, reliable groups can use a tool like this. Ano
by Rhapso 12y ago
Some paper reading shows that while interesting, the technique being used has issues with churn. This means small, reliable groups can use a tool like this. Anonymity is only provided within the group! You cannot hide your membership. In such a situation, anonymity is only improved by making the group larger and because their solution cannot handle churn, it will not scale larger.
In general anonymity and scalability seem to be at odds, so this is not surprising. A breakthrough showing this to be the case would be awesome but (I think) unlikely.
- coldcode 12y agoWhat does this churn involve? Too much traffic?
- Rhapso 12y agoChurn is when members join and/or leave. This protocol requires a fixed set of participants to start and they must all participate for it to succeed. So If I join late, I have to wait a cycle. If I leave prematurely, the cycle fails. The more participants, the more likely this is to happen.
- onion2k 12y agoCould that be mitigated by having a fixed number of available slots for participants, with each person taking an available slot, and random data submitted for any unused slots? Anyone leaving the cycle could send the same random data as if their slot hadn't been used, and in the next cycle random data would be submitted. Obviously there's a flaw that you'd need to predetermine the number of participants and choose a number of slots higher than that, and it'd be less efficient because you'd be sending data that isn't necessary, but might be worthwhile if the benefit of the communication is great enough.
- valarauca1 12y agoNot exactly. "Neighbor nodes" have to share cryptology data with one another for verification. If you simply join a session and you inherent data from the old seat, how do you know that the data you are being handed is valid? You don't unless you rebuild the cryptology verification with your "neighbor nodes". The problem is the theory and documents kinda of just hand-waves inter-node communication as being "unconditionally secure", which in practice is difficult to obtain.
- deleted 12y ago[deleted]
- brynosaurus 12y agoDissent is robust to churn among clients: communication rounds need not wait for the slowest client, and rounds can complete if some clients fail to show up. See the "Dissent in Numbers" paper for the details on how this works: http://dedis.cs.yale.edu/dissent/papers/osdi12-abs http://dedis.cs.yale.edu/dissent/papers/osdi12-abs There are caveats of course. This version of Dissent depends on a (small) number of servers, which are only collectively (not individually) trusted - only one of those servers needs to be honest and not colluding with the others for the security guarantees to hold, which is good for security. On the downside this means that the protocol is not robust to server churn - i.e., if one server fails, everything does grind to a halt. Other liveness/security balances are possible: e.g., we could require only a threshold number of servers to be live, at the cost of vulnerability to smaller colluding sets of malicious servers. Another caveat is that in any anonymity system in which client churn is present AND users maintain long-lived pseudonyms of any kind, client churn can be used by a smart attacker to de-anonymize clients via intersection attacks. This basically means that if you want "the strongest possible" anonymity protection, you basically either have to (a) never maintain pseudonyms or use time-linkable communication sessions at all (difficult!), or (b) eliminate client churn completely (also difficult!). Our Buddies paper explores this tradeoff and the (admittedly limited, so far) practical defenses that we can build against intersection attacks: http://dedis.cs.yale.edu/dissent/papers/buddies-abs http://dedis.cs.yale.edu/dissent/papers/buddies-abs Cheers Bryan