Silk Road forums

If you're on Windows (or 32 bit Linux), try the tutorial linked in my signature. It's worked for hundreds of other people.

You can download GPG4USB over Tor.

I think that's the scary part of all this. Ideally there should be some sort of mechanism that would recognize a guard node being taken over. I'm sure there's some algorithm that can figure that out.

Well, kmf is actually talking about a different attack from the one published in the paper that started this thread.

He's talking about a well known attack published in 2006 which you can read here: http://freehaven.net/anonbib/date.html#hs-attack06

That one doesn't require an entry guard to be taken over. It just requires LE to identify an entry guard by opening up many connections to the hidden service, and it's a lot scarier because it only takes 1-2 hours to find the entry guard, although probably days to weeks longer to monitor it and find the hidden service. However, that's way shorter than the 4-8 months it takes to carry out the attack in the recent paper. The best defense against the 2006 attack is layered entry guards, which are discussed in the original paper and still not implemented.

I'm still not 100% sure on how Tor works with the guard nodes and all the mechanisms in place. Whatever I've learnED has been pretty much reading your guys posts and some papers.

Correct me if I'm wrong but the guard nodes are random and no one knows where they will be exactly? Right? So LE does a timed attack to start eliminating possible nodes to hone in on the target? I think I understand why it's so diffucult to implement certain things in ToR.

Relays are given the entry guard flag by the directory authorities. Entry guards are chosen based on uptime and bandwidth. So right now there are about 3500 relays and 1200 entry guards. Here's a graph of how they change over time:

https://metrics.torproject.org/network.html?graph=relayflags&start=2012-02-29&end=2013-05-29&flag=Running&flag=Guard#relayflags

Your Tor client picks 3 entry guards and sticks with them for a month at a time. It does this "randomly" but based on bandwidth, otherwise small guards would be overloaded and the Tor network would be even slower. Your Tor client builds new circuits every 10 minutes, so before entry guards were created, your client would pick new entry nodes every 10 minutes. Going from 10 minutes to 1 month with the same entry nodes, you can see that was a big change in Tor client behavior.

In the 2006 attack, LE opens many connections to a hidden service, until one of them happens to pass through a node they control, which is one hop away from the entry guard. That way they can identify the entry guard.

In another situation I would just say let people assign their own guard nodes for their site but that just opens the doors for attack and makes ToR completely useless. It's quite the conundrum actually.

Allowing people to choose the nodes in their circuits would make their circuits distinguishable, because of individual biases in how they selected nodes, and that would reduce their anonymity.

Your anonymity is maximized when you look like everyone else, and more people that look just like you, the bigger your anonymity set. That's why you should stick to the defaults in your browser bundle, we all should, so we'll all look the same.

That being said, you *can* choose your own entry and exit nodes, it's just not recommended.

It's still worth noting that no hidden service has been deanonymized through a direct attack on the Tor network.

Maybe that's because LE is always 3 years behind the curve...

Very interesting... do you think something like that could work if I wanted to develop a website that cpu;d conduct financial transactions? I started another thread on how a site or application could be developed to anonymize transactions. Like for example how Liberty Reserve got shut down. Ideally a market place like Silk Road should have a currency exhanger or monetary transmitter that is not traceable. Now that's the flaw in the whole plan. The money has to go or come from somewhere right? It's not like I can apply the concept of Freenode and just deposit money into other peoples account and take it out later. Until that gets figured out one day it will be use playing catch up and not the Feds.

If you're talking about trades within bitcoin, there's Zerocoin.

http://dkn255hz262ypmii.onion/index.php?topic=152682.45

If you're talking about exchanging bitcoins for government-controlled currency, cash is the only (potentially) anonymous, untraceable government-backed currency, so cash for bitcoins seems like the only thing that would work.

Then you're back to face to face meetings.

My speciality is more on the programming/web side just learning about networks now but find it quite fascinating. Can you imagine how infuriating it is for a DEA agent knowing that there's a marketplace that sells drugs and uses their own post service to mail it out. That my friend is poetic justice at it's finest.

haha, I needed something to cheer me up man.

That makes a couple of assumptions.

One is that they can observe the traffic from the guard node.

Well, the attack is successful when they own the guard node, but becoming the guard node through random selection by the hidden service is what takes so long and costs so much money.

It is possible to configure your own nodes for guard nodes which blocks this attack.

Yep, that's basically what I was saying. Alternatively, if the hidden service operator didn't want to deal with anonymously purchasing extra servers for the entry guards, they could change the length of time that they keep entry guards:

/* Choose expiry time smudged over the past month. The goal here
* is to a) spread out when Tor clients rotate their guards, so they
* don't all select them on the same day, and b) avoid leaving a
* precise timestamp in the state file about when we first picked
* this guard. For details, see the Jan 2010 or-dev thread. */
entry->chosen_on_date = time(NULL) - crypto_rand_int(3600*24*30);

Change 30 to 180 and you've got entry guards for up to 6 months at a time, minus churn. Then it takes 4 years and $44,000 to achieve a 90% success rate with this attack. Adjust as needed.

The second and more common configuration of a hidden service is to proxy the traffic through tor. Although it gets more complicated to explain it makes it much harder to De-anomize a hidden service. Think of it this way, the hidden service has to connect to other stuff. By proxying it through a tor client it hides the tor requests for a hidden service from the guard nodes.

Are you talking about Tor over Tor, ie you run two Tor instances and proxy one instance (which serves the hidden service) through the SocksPort of the other? Because all hidden services work over Tor. In any case, I don't think Tor over Tor (or even layered entry guards) helps here, because the probability of the attacker becoming one of the first-layer entry guards is the same.

What about the DoS attack based on taking over the hidden services directory? How difficult to implement, and protect against is that one?

That is more worrying. It looks like it's easy for an attacker to pull of, and there's not much a hidden service can do to defend against it. It's not like messing with your entry guards or intro points, because in order for your visitors to figure out your configuration in the first place (like which intro points they can talk to you), they need to find your descriptor. That requires mutual assumptions made by both parties: for example, that I as your visitor can find your hidden service descriptor at a relay whose fingerprint is closest to the hash of your public key and the date.

They can make the descriptor ID unpredictable, for example by concatenating a random string to the hash of the public key and the date, and hashing that again, but that kind of solution needs to be implemented by the whole network, and new browser bundles must be distributed to users. They are working on it thought:

https://trac.torproject.org/projects/tor/ticket/8244

Really depends on what you're paying. For free shipping, I wouldn't expect anything better than this, although the smell shouldn't permeate Mylar / MBBs. If you expect the vendor to hide the goods inside an object, then be prepared to pay $10-30 for shipping.

To direct this attack at a specific hidden service, they write:

In early 2012 we operated a guard node that we rented from a large European hosting company (Server4You, product EcoServer Large X5) for EUR 45 (approx. USD 60) per month. Averaging over a month and taking the bandwidth weights into account we calculated that the probability for this node to be chosen as a guard node was approximately 0.6% on average for each try a Tor client made that month. As each hidden service chooses three guard nodes initially, we expect over 450 hidden services to have chosen this node as a guard node10 . Running these numbers for a targeted (non-opportunistic) version of the attack described in Section VI-A shows us that by renting 23 servers of this same type would give us a chance of 13.8% for any of these servers to be chosen. This means that within 8 months, the probability to deanonymize a long-running hidden service by one of
these servers becoming its guard node is more than 90%, for a cost of EUR 8280 (approximately USD 11,000).

Granted, $11,000 and 8 months isn't impossible for some LEA to spend to identify a very high value hidden service, but it's also not a trivial attack, and it still depends on the hidden service having a normal entry guard configuration and rotation period.

Have you tried some random RAR file as a test, like the one I linked above?

We can at least figure out whether it's the archive manager or the archive.