Silk Road forums

Post offices are the tip of the iceberg. Every office building is like that. Think about all the 30+ story sky scrapers in every major city. They all run heating and AC throughout the night, when no one except maybe a few guards and maintenance people are in them.

We are spectacularly wasteful, which is why the average American consumes something like 200 times the energy of the average person in the third world.

BTW, how many miles per gallon does that car that you drove to that post office get?

Great info Astor, but as I'm not a technical person in this side of technology (I know only what I need to really with a bit around the sides), doubling the key strength to 2048 wouldn't give double the time it can be used would it as technological capability grows at an exponentially faster rate?

You're not doubling the key space. You're increasing it by 2^1024. A 1025 bit key is twice as big as a 1024 bit key. 

For symmetric encryption, it would increase the time that it takes to brute the key by a factor of 2^1024, or around 10^308, not accounting for Moore's Law. We had a discussion about key strengths a few months ago, and what I learned is that asymmetric encryption, which includes RSA and other schemes used by public key crypto protocols (including PGP), differs in that the key space is the number of primes within some range of numbers, which of course is much smaller than the total range of numbers. That's why 128 bit AES symmetric keys are stronger than 1024 bit RSA asymmetric keys, and won't be cracked until long after 1024 bit RSA keys are cracked.

So for Tor's public key authentication mechanism, it won't increase the brute forcing time by 10^308, but it will future proof the keys for many decades.

So what would a drastic step  in key strength mean for the Tor network? Would it increase loads, slow things down etc? Just want to get some clear answers on this if anyone can help

It will increase CPU usage on the relays, and that seems to be the bottleneck on the network right now (not bandwidth). I'm not sure if that increase will result in a noticeable slow down of the network.

Hidden services currently use 1024 bit RSA private keys for authentication. (An onion address is the base 32 encoded first 80 bits of the SHA1 hash of the public key that corresponds to the hidden service's 1024 bit RSA private key.) 768 bit keys can already be cracked by computer clusters in about 100 days, which is considered reasonable effort for some targets -- which probably includes SR. 1024 bit keys will be cracked in the next 5 years. So, the Tor Project needs to update the crypto mechanism to support larger identity keys (this will affect relays as well as hidden services, but it's more important for the latter).

If the hidden service private key is updated, the onion address will change. This is an issue in our community with so many phishing sites and the general paranoia (mostly justified) about accessing the correct site. So you all should be aware that Silk Road's private key will have to be updated at some point, and the onion address will change. They're starting a discussion about this issue on the tor-dev mailing list. Here's the first email:


https://lists.torproject.org/pipermail/tor-dev/2013-May/004848.html


Greetings,

I'm supposed to write a Tor proposal for the migration of the
long-term identity keys of Hidden Services. When I began writing the
proposal, I realized that some of my choices might not be appreciated by
Hidden Service operators, and that starting a discussion thread might be a
good idea before writing the proposal.

The problem with the current long-term HS identity keys is that they
are RSA-1024 keys which are considered weak, and they need to be
upgraded to a cryptosystem with higher security properties.

One of the main issues with this operation, is whether Hidden Services
will be accessible using their *old* identity keys even after the
migration.

That is, when we change the identity keys of a Hidden Service, its
onion also changes (since the onion is the truncated hash of its
public key). This will be quite problematic for Hidden Services that
have a well-established onion address.

There are basically two ways to do this:

a) After the transition, Hidden Services can be visited _only_ on
   their _new_ onion addresses.

   This is quite brutal, but it's the most secure and unambiguous
   option (might also be easier to implement and deploy).

   This change can be enforced both on the client-side, by rejecting
   any old RSA-1024 HS keys, and on the server-side, by only
   publishing the new keys in HS descriptors.

   To make the transition easier, we could prepare a tool that
   generates a new identity keypair before the flag day, so that
   Hidden Service operators can learn their future onion address
   beforehand and announce it to their users.

b) After the transition, Hidden Services can use both old and new
   onion addresses.

   This might result in a more harmonious transition, where Hidden
   Services advertise their new onion address to users that visit
   them in their old address.

   .oO(It would also be interesting to do a redirection on the Tor
   protocol layer ("I got this descriptor by querying for the old
   onion address, but it also contains a new onion address. I should
   probably use the new one."), but I don't think it's possible to
   redirect the user without knowledge of the application-layer
   protocol (e.g. 302 for HTTP). Still, a Tor log message might be
   helpful.)

   The cons of this approach is that supporting both addresses might
   make the HS protocol more complicated and painful to implement, and
   it might also result in some Hidden Services never moving to the
   new onion addresses since clients can still visit them using the
   old insecure ones.

   This approach has a stricter variant, where the old addresses can
   only be used during a transitionary period (a few months?). After
   that, clients _have_ to use the new addresses. Of course, this
   means that we will have to do two flag days, coordinate Tor
   releases, and other no fun stuff.

I'm probably moving towards the latter option because the former will
make many people unhappy.

Thoughts?

(This is not a thread to select the cryptosystem we are going to
use. It will derail the discussion, and we might also need to select a
specific type of cryptosystem in the end (e.g. a discrete-log-based
system) so that schemes like
https://trac.torproject.org/projects/tor/ticket/8106
can be possible.).

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Are you talking about cert-digest-algo?

It forces a specific hash algorithm, for example the SHA512 hash on this clear
signed message. The standard is SHA1 (like in DPR's signed messages), but it is
becoming obsolete. Some PGP programs use MD5, which is retarded.

The GPG manpage does warn that you shouldn't force cert-digest-algo, because
some PGP programs don't support SHA512 for message hashing, but I say fuck em.
If your PGP program fails to verify a signed message because it doesn't support
SHA512, you need a better PGP program.

We shouldn't reduce our safety for the lowest common denominator.

-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJRlBNAAAoJENAcophwbuIHGYcQAJSwUhtv825TCVnixETLUDg7
VC4p6ZfMBFQvyeDD4l/WngF3nxHmt+3W0zO8WqRGlQ+XUvxPZeSMUlmnB5e0GTkB
up6zl60ptkBy24k72sV026jWscpBsUm8UqW8wR+WtnPnQ4dUt/0YDowBjbzXJcsz
OO8bvzmaGWlz4HXK8CvGgJufT9P20vp5bIzaM8Ma2dAGaqM8DNJiNNtqeWftN82R
2SFzJfLLsXxMTtP8KmnPg3xrdey5bleuIadjeuvcHWVDdKcH87DkLgdcAArT/Ijz
AqSkei0rnoUGkZ2gv3430L1FqS6qhs6j7wtxl1p6OX2kPvNlRJwT0UIWml3Ac9+f
1kaWeofhJReyRWfJQXaRM+fWV8OmQd7tmBDlc4BmI+EzQaUCRqi31aCtr89cRfh2
i1CgDcANz9G2ICLSir2gm9kZz3mjzPrrEi2J0WxfakYQnUaLTvqGBdB3z309JBfC
t5LWwN6ZorrVPKNOm6MRrwVzZXq2reucZRP87qjLEBCyrwmWFVQdpC2NIuRaQnqb
vmwYDEMBfDA2V2aXEJlVxNO/57bYOCr1j/y5Zb9EcNvzJJZFYfU3eNOQi4ctb6tO
4OVPs2OTEpQTcZkR7PwqD34jP/9GmMgNLK2bzi+WiN6DjUABt2vARGMsIK++sWHw
GMtofrIItdIgqZ9tCrKm
=Wy6i
-----END PGP SIGNATURE-----

You know, it's entirely possible that MtGox will be shut down now for FinCEN violations. This would be devastating to the bitcoin market for a while, but from it's ashes many smaller, distributed exchanges could flourish, along with alternative F2F methods of getting bitcoins, which would be more robust to these kinds of shut downs.

Re: OTC / localbitcoins.com, the FinCEN rules say that anyone who buys / sells more than $1000 in BTC a day is an MT/MSB and subject to their rules.

So I wouldn't trade more than that on the OTC market, as those are the people they are likely to set up stings against at some point.

I have heard of a few like SuperFakes, EnterTheBeers, and Drinker875 but two of them require FE and the one that has good stealth keeps getting mediocre reviews.

Stay away from Frothy76. Known scammer.