rBridge tolerates up to ~30% malicious users with acceptable bridge protection, but fails at f≥50%; with f=5% under aggressive blocking, over 95% of users are never bridge-starved and ~50% of bridges are never blocked, while conservative blocking (corrupt users waiting 225 days before acting) causes ~10% of users to be thirsty 15% of the time because delayed blockers accumulate enough credits to inject additional malicious invitees.

In simulated event-driven (crisis) blocking where all corrupt users simultaneously block bridges on day 300, available bridges drop from ~500 to ~150 and thirsty users spike to 25%; maintaining 50 reserve bridges (~10% of deployed stock) halves the thirsty-user count, and 100 reserve bridges nearly eliminates thirstiness among users who had accumulated sufficient credits.

§4.3.2 evaluation

Knowing a user's bridge assignment narrows the adversary's anonymity set to the small group sharing that bridge, deanonymizing Tor users even when the bridge itself is not compromised; rBridge addresses this using 1-out-of-m Oblivious Transfer, Pedersen commitments, and non-interactive zero-knowledge proofs so the bridge distributor learns nothing about which bridges a user holds.

§5, §5.1 defense

China's GFW was able to enumerate all Tor bridges distributed via IP address or Gmail account in under a month, demonstrating that standard small-subset distribution strategies are insufficient against a state-level adversary controlling large numbers of accounts and Sybils.

§2.1 detection

rBridge outperforms Proximax by at least one order of magnitude across all robustness metrics under aggressive blocking with 5% malicious users: to support 200 users for 30 days, Proximax requires at least 2400 bridges while rBridge needs only 108, and in Proximax fewer than 5% of bridges produce more than 20 user-hours versus 99% in rBridge.

§4.3.3 evaluation