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: 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