Silk Road forums

Oh btw, this is the highest quality version of this book that I've found   http://libgen.org/search.php?req=total+synthesis+strike

Most of the PDFs floating around as torrents are horrible scans.

First Coding Challenge: write a Python script that scrapes the SR web site for all vendor keys and saves them in a text file.

I taught myself, starting with Python. Did a lot of web tutorials and stuff, but to be honest, if you don't have a comp sci background, there's no substitute for a good book. I learned 10 times as much from Learning Python by Mark Lutz as I did from all the web guides combined. Understanding fundamental concepts is more important than memorizing a bunch of syntax.

At least they're dumb enough to use fake signatures, so you can prove it's a scam within 30 seconds.

Yep, for onion sites, http is safe.

For clearnet sites, you must use https for entering sensitive info.

Now that you know that, disable the warning and don't worry about it. It's a dumb a warning that doesn't understand the complexities of Tor.

Frankly, Pine, I'm a little surprised that you haven't mentioned any suspicions about me being the same person as him and just coming back to try again or something.  Honestly I only mention it because it really does seem plausible.  I mean I'm certainly not him and didn't even know he existed, but after looking him up I'm a little surprised that not a single person has even mentioned it.

haha, how did I miss this.

I was convinced that pine and LC knew each other in real life, because they both disappeared around the same time and showed up on the same night, months later. I was not the only one who noticed this coincidence. It looked like they planned it. Also, the sexual tension in the "LC is LE" thread is unmistakable.

Since then it's pretty much been proven to me that they don't know each other. And no, I never thought you were LC either. IDK,  your styles and technical expertise are distinctly different to me.

Found some great info on the difference between RSA and AES, straight from RSA Laboratories.

https://www.rsa.com/rsalabs/node.asp?id=2004

It's a long article and well worth a read. Here's a table of how RSA keys compare to symmetric keys like AES, and the approximate year when they are expected to become unsafe:

1024 RSA    80 sym      by 2010
2048 RSA    112 sym     by 2030
3072 RSA    128 sym     beyond 2030

So in 2003, when the article was written, they thought 1024 bit RSA keys would have been cracked by now. Apparently, computational power hasn't increased as much as they expected, but it's about time to upgrade Tor's crypto now. 2048 bit keys will be safe for another 20 years, and if you use a 4096 bit PGP key like me, you should be good for the rest of your life.

Along with the private key size increase, onion domains may become longer. This is pretty much inevitable to prevent brute forcing. For example, taking the first 120 bits of the SHA1 hash and base32 encoding that, you'd get a 24 character onion address instead of the current 16 characters.

So if Silk Road updates to the new system, their address would look more like:  silkroadvb5piz3rugc6xecq.onion 

Phishing sites are going to have a field day.


Also, someone on the mailing list offered petnames as a third option in the migration plan:

============

I think you were heading in the right direction with the petname idea.
What if we deployed a potentially shitty naming layer that "probably"
won't break within the next 6-12 months, but *might* last quite a bit
longer than that, for backward compatibility purposes.

This naming layer could allow interested parties to sign registration
statements using their current onion key with an expiration time,
satisfying our deprecation desires for the 80 bit name. If the naming
layer actually survives without visible compromise until that point, we
could allow it to store signed statements about translations between the
new keys and their desired name (first-come, first-serve; names are
reserved for N months until resigned).

A more specific version of this question is: How readily could we hack
Namecoin or some other similar consensus-based naming system[1] into
Tor?

Such a mechanism would obviously provide enumeratability for hidden
services that chose to use it, but hopefully it would be optional: you
can still use IP addresses in browsers, after all.


In terms of verification, it would be trivial to alter the browser UI to
display the actual key behind the hidden service (ie: through a control
port lookup command and some kind of URL icon that varied depending on
consensus naming status).

We could also provide a hacked version of CertPatrol that monitors the
underlying public keys for you, and it would also be relatively easy to
add a "second-look" authentication layer through the HTTPS-Everywhere
SSL Observatory, similar to what exists now for SSL public keys.

In fact, if we can agree on a solid consensus-based naming scheme as a
valid transition step, I think it is worth my time to let the rest of
the browser burn while I implement some kind of backup authentication +
UI for this. After all, memorable hidden service naming would be a
usability improvement.


Should we try it?

The major downside I am seeing is PR fallout from the hidden services
that chose to use it.. They might be a unrepresentative subset of what
actually people need hidden services for. I think the real win for
hidden services is that we can turn them into arbitrary private
communication endpoints, to allow people to communicate in ways that do
not reveal their message contents *or* their social network. There
probably are other uses whose promise would be lost in the noise
generated from this scheme as well...



1. https://en.wikipedia.org/wiki/Namecoin.

We don't have to choose Namecoin, though. Another alternative is for the
dirauths to add a URI for an "official" naming directory file as a
parameter in the consensus consensus, and also provide its SHA256/SHA-3.
A flatfile might be less efficient than Namecoin in terms of storage and
bandwidth requirements, though. It's probably also easier to censor
(unless it is something like a magnet link).

For all you Zooko's Triangle[2] fans: The Namecoin mechanism attempts to
"square" the triangle with a first-come first-serve distributed
consensus on the pet names document, but still fall back to
"Secure+Global" at the expense of "Memorable". The interesting bit is
that in this case, the browser UI can help you on the "Memorable" end,
should the consensus mechanism fail behind your back.

2. https://en.wikipedia.org/wiki/Zooko%27s_triangle

Are you sure those connections belong to Tor?  netstat -an doesn't show you that info. netstat -ano will show the process IDs, but then you have to find them in the list of running processes, so you might try something like TCPView. Also, have you confirmed that the outbound connections are going to Tor relays?

It's puzzling, because the Tor that's included in TBB hasn't changed since December, so it shouldn't have magically stopped working. Maybe Vidalia isn't writing the Tor options to torrc correctly? You could manually add them by shutting down TBB, opening torrc with a text editor adding either,

for Socks5 proxy: Socks5Proxy <host>:<port>

for HTTP proxy: HTTPProxy <host>:<port>

Maybe Vidalia isn't forcing Tor to reload its configuration file, so try simply restarting it first.

Also, you're not trying to run Tor over Tor are you? That's bad when connecting to clearnet sites, because your entry and exit node could be the same relay.