Running a COR network matching Tor's 2011 aggregate bandwidth (estimated at 150 MB/s end-user demand, ~376 TB/month) would cost approximately $61,200/month on Amazon EC2 at July 2011 pricing. A single EC2 node at 17¢/hour plus bandwidth charges can relay approximately 110 Mbps and support up to 100 concurrent users at ~1 Mbps each; m1.large and c1.medium instances handled 100+ concurrent connections while t1.micro struggled beyond 10.

Cloud-based onion routing confronts censors with a collateral-damage dilemma: blocking a cloud provider's IP prefixes requires blocking all co-hosted services (Amazon EC2 hosted over 1 million instances sharing common IP prefixes in 2010), while allowing the traffic means circumvention succeeds. Rotating IP addresses—by retiring and spinning up new VM instances or via DHCP/gratuitous ARPs—reduces the window a blocked address remains in service, forcing censors into a perpetual cat-and-mouse game across all major cloud providers simultaneously.

§2.3 defense

In controlled benchmarks using TorPerf, the best COR circuit achieved a median file download time 7.6× faster than Tor across 50 KB, 1 MB, and 5 MB files (100 repetitions each). COR was also several times faster than Tor for downloading full web pages across the top 10 Alexa domains, even when COR relays were serving 50 simultaneous connections.

§4.1, §4.2, Figure 3 evaluation

COR does not solve the bootstrapping problem: a user's first connections to the COR bootstrapping network are vulnerable to the same IP-enumeration and blocking attacks as public Tor directory connections. To mitigate directory-partitioning attacks, directory retrieval is always performed through an existing COR circuit, and directories return only a random subset of available nodes rather than the full list—but this subset-delivery design is itself exploitable by a malicious directory that can fingerprint users via uniquely-assigned relay subsets.

§2.3, §3.1, §5 defense

COR circuit construction enforces four properties to prevent single-entity de-anonymization in a limited-provider setting: (1) entry and exit ASPs must differ; (2) entry and exit CHPs must differ; (3) the same ASP's relays must not surround another ASP's relay without an intervening hop of a distinct ASP; and (4) at least two relays per traversed datacenter so an adversary with only perimeter visibility cannot trivially correlate ingress/egress.

§2.4 defense