[tor-dev] Discussion on the crypto migration plan of the identity keys of Hidden Services

[Jeroen Massar]

On 2013-05-17 15:23 , George Kadianakis wrote:
[..]
> 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.

(just a brain ramble might be something useful, might be useless ;)

Each hidden service could run, on a given port/protocol, a service that
answers with the hashes it is responsible for (a 'service packet'), eg
by signing the packet with each of those sigs. The client can thereby
know that that service is available as different hashes.

The 'service packet' could indicate a 'hash preference' thus enabling
the client to pick the 'preferred' hash, and effectively allowing
multi-homing of the service if the preferences are the same and/or
allowing moving to a new crypto key, quite transparently, as the
old-hash is still available and can be checked.

Note that it requires being able to sign those packets with the new
hash, thus one has the private key for being able to do that, no
cheating would be possible.

The 'service packet' could contain a "well known name" or "description"
so that these packets can be stored/indexed and the user can use this
identifier for accessing the service.

Of course, the question also becomes 'is the old one still valid or has
it been compromised', that is a hard one to answer... I guess having an
expiry of a key would be a good thing.


An alternate approach, given a DNS tree where due to DNSSEC it is
trusted (yes, that comes with a lot of it's own caveats ;) ) one could
state hidden.example.com has a CERT [1] record which has hash X and hash
Y. That would be the forward mapping at least. A DANE[2] alike system
also come to mind.

[1] https://tools.ietf.org/html/rfc4398
[2] https://tools.ietf.org/wg/dane/

Greets,
 Jeroen