Silk Road forums

You need to import the seller's public key into your PGP program. Their public key should be listed on their seller profile. It will begin and end with these lines:

-----BEGIN PGP PUBLIC KEY BLOCK-----

<bunch of gibberish>

-----END PGP PUBLIC KEY BLOCK-----

You didn't mention the PGP program that you're using, so I can't give you specific instructions. Just make sure you copy the entire thing, including all fives dashes before and after the text, in the first and last lines. That's a common mistake. A single missing dash will cause the PGP program to not recognize it as a public key.

Once it's imported you should be able to select that vendor as the person you want to encrypt the message to.

The output will be the encrypted message, which will begin and end with these lines:

-----BEGIN PGP MESSAGE-----

<bunch of gibberish>

-----END PGP MESSAGE-----

Copy that whole thing, including all dashes, and paste it into the form for submitting your address.

As a buyer you only need a public key if you want other people to send you encrypted messages. You must give them your public key. PGP is an asymmetric encryption system, where you always encrypt messages to the recipient's public key (although you can encrypt to your own key as well, if you want to be able to read your own messages; there can be multiple recipients).

You could set up your own kind of certificate-style trust mechanism for the darknet, where you list people who you trust and only deal with those certified by these trusted parties (a highly decentralized version of certificate authorities for SSL, more for certifying trustability than authenticity though). Anonymity makes trust an absolute bitch to handle, but you can still corrolate trust. If a high volume, trusted vendor on Silk Road decided to start up a marketplace (and used PGP or similar to verify their identity) then you'd be a lot more confident than random new hidden service.

A bit beyond the scope of this project, but it's a cool thing I wouldn't mind getting in to!

Actually, that reminds of the Freedombox. Are you familiar with it? It's a software stack that's supposed to run on a plug computer and provides various services (email, blog, social network) in a privacy-respecting way (distributed, versioned, encrypted back ups, etc). One cool proposal they came up with was in backing up PGP private keys securely. You could select say 5 or 6 (or 20 or 50) trusted friends and send each of them pieces of your private key. They would all have to collude to pwn you, which presumably they wouldn't because you selected people you could trust. If you lost your key, then you contact them, and after they verified who are you, you could reconstitute your private key. Voila! Distributed trust.

That would be more difficult in a truly anonymous network, but it sounds similar to what you were saying. I know you were talking about the web of trust model.

We had a short discussion over here

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

We want to assure you that there is demand for such apps too!  Especially the high and middle tier traders WILL NEED such apps for their private markets and dealings.

There's a trade off in moving from centralized to distributed markets. If you look at the Hidden Wiki right now, you'll see that it's spammed by a "vendor" named Eris. You can follow the links to his hidden service. Nobody knows anything about this vendor. Would you send BTC to him? The big value add of SR is that it's a central repository of ratings and reviews that builds confidence in making transactions. If you run your own private market, who should believe your reviews? Will there even be any? Will the whole thing depend on an independent review system?

The social and behavioral economic aspects of anonymous markets are another hard problem, but this one can't be solved by math or coding skills.

What do you plan to do about some of the well known attacks for discovering hidden services?

If they didn't raid your house within a few minutes of delivering the package, you're fine. They won't give you a chance to get away with it. I'm also pretty sure if they planned a raid, they wouldn't put a big sticker on the package warning you about it. Perhaps methylone doesn't come as anything on field tests. They didn't know what it is, but they knew it wasn't a (known) controlled substance, so they let it go.

Of course they can do that, but they wouldn't do it with the Browser Bundle running on their DEA office computer.

There is a command line version of Tor with no Vidalia, which is what most Tor relays are running. It's possible that LEA in various countries are operating some of these relays. The easiest attack is simple timing / traffic analysis. If LE controls your entry guard and exit node, they can see who you are and what site you are accessing. The probability of picking two malicious nodes like that is (c/n)^2, where c = number of malicious relays, n = total number of relays. It's more complicated than that, because your client picks relays with a probability weighted by bandwidth, but lets go with that as a first approximation.

If the DEA operated 50 relays, the chances that you pick 2 of them for your entry and exits is (50/3000)^2 = 1/3600. That's a relatively small chance for a rather large number of relays that they would have to operate, however, if you picked different entry nodes every ten minutes (when you build a new circuit), you would quickly get pwned (on the order of weeks). But that's why entry guards exist. You stick with three of them for a few months at a time, so it would take years to cycle through them until you picked from the DEA nodes.

That's on average. Some people would get pwned faster than others. It's the luck of the draw. But the point is that the entry guards greatly improve your safety, which is why you should not follow the advice of some "improve your Tor performance" guides that say to increase the entry guards to 8. That can potentially get you pwned faster.

All of this only applies to visiting clearnet sites. There are no exit nodes with hidden services. LE can't do a traffic confirmation attack because they don't know where the other end of the circuit is (although there are some well known attacks for identifying hidden services).