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.).