Silk Road forums

Figured some people would be interested in this.

http://dedis.cs.yale.edu/2010/anon/

The Dissent project is a research collaboration between Yale University and UT Austin to create a powerful, practical anonymous group communication system offering strong, provable security guarantees with reasonable efficiency. Dissent's technical approach differs in two fundamental ways from the traditional relay-based approaches used by systems such as Tor:

Dissent builds on dining cryptographers and verifiable shuffle algorithms to offer provable anonymity guarantees, even in the face of traffic analysis attacks, of the kinds likely to be feasible for authoritarian governments and their state-controlled ISPs for example.

Dissent seeks to offer accountable anonymity, giving users strong guarantees of anonymity while also protecting online groups or forums from anonymous abuse such as spam, Sybil attacks, and sockpuppetry. Unlike other systems, Dissent can guarantee that each user of an online forum gets exactly one bandwidth share, one vote, or one pseudonym, which other users can block in the event of misbehavior.

Dissent offers an anonymous communication substrate intended primarily for applications built on a broadcast communication model: for example, bulletin boards, wikis, auctions, or voting. Users of an online group obtain cryptographic guarantees of sender and receiver anonymity, message integrity, disruption resistance, proportionality, and location hiding.

See our CCS '10, OSDI '12, and USENIX Security '13 papers describing the experimental protocols underlying Dissent. Also feel free to check out the source code at the link below, but please keep in mind that it is an experimental prototype that is not yet ready for widespread deployment by normal users.

Yep, well now it's more like 600, so we're getting there.

OTOH, I have noticed a slowdown of the network, and more of my connections have been failing, even to clearnet sites. Bandwidth hasn't increased (these million new clients don't seem to be doing much), but the network may be slower because the relays have to manage three times as many circuits, which requires CPU power to do the crypto operations, and that's always been a bottleneck.

If a million people just joined the network, some of them should run relays. I'd like to see 10,000 on the network.

Sadly, whenever there's a huge spike in Tor traffic, nobody seems cheery about that.

I'm cheery about this one. The metrics data shows a small increase in lag, but nothing noticeable while browsing. Meanwhile, we have 1.4 million Tor users instead of 500,000. Our anonymity set just tripled.

Say if one were using public obfs2/obfs3 bridges, how well would would that really protect you from your ISP seeing your Tor usage?

The Chinese government already cracked obfs2. They can DPI it. They also enumerated all bridge IP addresses a couple of years ago. The Tor Project should be doing a better job of dividing the BridgeDB buckets and detecting mass enumeration attempts, but it's possible the NSA or other intelligence agencies could have enumerated them. OTOH, the churn might be high enough to supply a decent pool of IP addresses at any one time. So far there is no documented evidence that anyone can DPI obfs3.

The answer to your question is that nobody knows for sure, but using an obscure VPN provider in combination with obfs3 bridges is your best option for membership concealment in the Tor network.

Obfsproxy is a protocol that only bridges use, and only a subset of them, so there are no entry guards involved. By using obfsproxy, you are ostensibly already hiding your Tor use because you are using a bridge. Well, you are hiding it from IP address scanners, but the connection can still be DPIed, which is what obfsproxy is for.

You have to manually select obfs2 or obfs3 bridges from the BridgeDB (https://bridges.torproject.org) to use obfsproxy. You also need a special browser bundle:

https://www.torproject.org/docs/pluggable-transports.html.en#download

Astor actually brought up a good point and I am struggling to find a perfect solution. Although the content on EKS servers is encrypted, we should assume that the people running the servers will be able to obtain keys for certain content, we should also assume that some of them are malicious and could try to censor information. There are distributed PIR schemes that hide the content of the database from the servers, but a client that queries the database still does so by index position. That means if an entity that runs a PIR server also runs a client, and the client knows a certain message is at index 42, the PIR server can then link the secret share at position 42 to the message downloaded by the client. So even Goldbergs PIR will not work to solve this problem. The problem is characterized as follows:

Given a server or cluster of servers hosting a database, how can we have it so that:

A. Clients can request specific files from the database (via position or keyword)

B. The servers hosting the database cannot determine the clients query (ie: servers cannot tell the position requested or keyword searched for)

C. The servers hosting the database cannot tell the files returned (ie: they do not know what they send back to the client)

D. The servers hosting the database cannot tell the files hosted (ie: they cannot ever see any content that the client eventually obtains, during storage or transfer)

E. An entity that owns a client and a server cannot download a known file from the database in order to be able to associate content on the database with the file (ie: the server cannot link data it hosts to content even if it downloads the content partially from itself while acting as a client)

I think this problem is solved by querying multiple servers. Unless an adversary runs all or almost all nodes, you will be able to retrieve the content. Comparing the results of multiple queries from different nodes will allow clients to determine which ones are censoring, and even what kinds of content they are censoring, and the clients could blacklist those nodes.

In the end, censorship is simply impractical if the network of nodes is big enough.

If an attacker has access to the thumb drive and finds a way to get your paraphrase or to break the encryption, it becomes available to see.

Tails with a persistent volume is vulnerable to the same attack, and that's how most people here use it. I think the plan is to flush it down the toilet so there's no trace of even a Tails system image on any storage media in their possession. Somebody said in a thread recently that their thumb drive is so small they can swallow it.

So Qubes on a thumb drive is not worse that Tails in that respect, but it's better because of VM isolation (although you have to setup a Tor VM, whereas on Tails you manually have to add bridges).