Dissent 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. S

Dissent 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