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