Silk Road forums
Discussion => Security => Topic started by: astor on May 17, 2013, 01:44 pm
-
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.).
-
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?
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 :)
-
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.
-
+1 for you sir!
I have personally put much money into relays, in the past year probably over £5,000 worth of donations in bitcoins for people/organisations to run relays for me and of course they've no idea who I am since I don't want to affiliate myself with them given the trouble some exit relays have. I'd like to see other vendors or even SilkRoad itself putting some money towards this since right now a lot of the network traffic passes through just a handful of exit nodes and this is bad.
For future-proofing SilkRoad into the decades, we must also consider the threat of Quantum computing. Has any proper analysis been done to what kind of threat this could pose, I guess not only to SilkRoad but many other internet protocols? I believe quantum computers do exist, although primitive right now, but that doesn't mean the government can't make one and not tell the public about it which is why I am concerned.
-
No question about it. This is like Microsoft trying to make everything backward compatible -- you end up with bloatware.
Look at the number of users, there are VERY few on the darkweb. We can migrate.
Make it robust, secure, fast and safe. Eeryone will migrate to the newer, better darkweb. Death to 1o24, ong live NSA resistant distributed darkweb.
I hereby pronounce and proclaim the new WWW as DDD Distributed Deep Darkweb!
MAKE IT SO.
Modzi
-
They should have made the system support a range of key sizes to begin with. At least they are going to do that now, so you will be able to use keys up to 4096 bits, I believe.
-
They should have made the system support a range of key sizes to begin with. At least they are going to do that now, so you will be able to use keys up to 4096 bits, I believe.
I'm not even sure what such a low key strength would be used to begin with. My PGP key strength is 4096 bits and I use it because I know it is much more future-proof. Why settle for something less secure?
-
The onion is blooming.
-
I'm not even sure what such a low key strength would be used to begin with. My PGP key strength is 4096 bits and I use it because I know it is much more future-proof. Why settle for something less secure?
1024 bits was pretty strong 10 years ago when they wrote the initial code. :)
Since then they've been delaying the inevitable because 1024 bits was "good enough" and existing hidden services would be screwed. Now it's getting dangerously close to not being good enough anymore.
For future-proofing SilkRoad into the decades, we must also consider the threat of Quantum computing. Has any proper analysis been done to what kind of threat this could pose, I guess not only to SilkRoad but many other internet protocols?
Sure, it's well known that RSA is weak to quantum computing.
The good news is that people are already working on algorithms that are resistant to it:
https://en.wikipedia.org/wiki/Post-quantum_cryptography
-
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
-
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.
That is true for symmetric encryption, but not for asymmetric encryption. If I recall correctly, for RSA based asymmetric encryption you are increasing the key space from the number of 1,023 bit prime numbers to the number of 1,024 bit prime numbers. For symmetric encryption you increase the key space from the number of 1,024 bit numbers to the number of 1,025 bit numbers.
What they should really do is switch to ECC. Much faster than RSA, much smaller keys, superior properties over all. RSA is kind of outdated these days.
-
Everyone here is learning the patience required for security: hours/wk reading times, TOR, encryption, etc.
I would be happy to let my computer to go through encryption protocols to ensure 3000+ bit encryption. On a non-quantum PC, a quantum patience is mandatory.
If the U.S. government is truly storing all communications, then we should invest in a 30 year encryption plan--where we estimate the encryption needs on its current rate of development and commit to intensive cryptographic techniques...
Stay Ahead of the Curve
-
What slow ass loading compared to security
-
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.
I imagine it will.
P.S. - subbing :)
-
sorry- just want to be able to find this later
-
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.
Really? Has anyone tried offloading this work to GPU using Cuda or similar? That would be quite an interesting project.
-
Some relays are already using AES-NI, which should be even more efficient, since it's specifically designed for crypto operations. Crypto still seems to be the bottle neck.
-
From time to time, I use AES to encrypt my communications. It is a four step process, where I use 3 public keys provided by the recipient.
1. Encrypt message with public key #1.
2. Encrypt encrypted message with public key #2.
3. Encrypt doubly encrypted message with public key #3.
4. Send.
If the recipient has pissed me off, then I will not use the encryption in that order: 1-3-2 or 3-2-1 or something.
Furthermore, it is also wise for millionaire BTC holders to invest in hardware that utilizes encryption independent of the computer in order to eliminate software insecurities, such as OS or firewall SNAFUs.
Privacy is NEVER A WOFTAM.