On Tue, Apr 08, 2014 at 02:15:12PM -0500, Nicholas Hopper wrote:
Interface
To use this feature, a router should rename its secret_id_key file to secret_id_key_OLD. The first time that Tor starts and finds a secret_id_key_OLD file, it generates a new ID key if one is not present, and generates the text of the old-rsa-1024-id-key and old-rsa1024-id-migration fields above. It stores them in a new "old_id_key_migration" file, and deletes the secret_id_key_OLD file. It includes them in its desecriptors.
I guess it's possible a relay operator could shoot themselves in the foot here by causing some inconsistent state between these three files. I guess at worst, though, this should again be a case where the window of vulnerability is small, so very few (or possibly no) relays would lose their history this way.
I'm a little wary of having the tor binary perform an irrevocable operation like deleting the old key file. Maybe have it rename it? Or only delete the file once the migration has appeared (and the signatures verified) in a consensus or five?
- Ian