[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
[tor-dev] Discussion on the crypto migration plan of the identity keys of Hidden Services
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.).
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev