-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
Hi everyone,
Two months ago I decided to try the new ed25519 key introduced in Tor 2.7 with OfflineMasterKey set so I can keep the master key in a different place and just upload the medium-term signing key every month. Last month everything went ok: I renewed the key and Tor accepted it. This time instead after generating the new signing key with
# tor --datadirectory path_to_my_master_key --signingkeylifetime '1 months' --keygen
and uploading ed25519_signing_cert and ed25519_signing_secret_key and fixing the permission, Tor keep saying
Feb 03 07:27:40.000 [notice] It looks like I need to generate and sign a new medium-term signing key, because the one I have is expired. To do that, I need to load the permanent master identity key. Feb 03 07:27:40.000 [warn] We needed to load a secret key from /var/lib/tor/keys/ed25519_master_id_secret_key, but couldn't find it. Did you forget to copy it over when you copied the rest of the signing key material? Feb 03 07:27:40.000 [warn] Can't load master identity key; OfflineMasterKey is set. Feb 03 07:27:40.000 [err] Error initializing keys; exiting
That raises two questions to me: - why does Tor think the new keys are already expired? - why is Tor searching ed25519_master_id_secret_key? With OfflineMasterKey set it shouldn't care about the master secret key
Thank you, patacca
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
Hello - see inline
On 2/3/2016 3:49 PM, Riccardo Mori wrote:
Hi everyone,
Two months ago I decided to try the new ed25519 key introduced in Tor 2.7 with OfflineMasterKey set so I can keep the master key in a different place and just upload the medium-term signing key every month. Last month everything went ok: I renewed the key and Tor accepted it. This time instead after generating the new signing key with
# tor --datadirectory path_to_my_master_key --signingkeylifetime '1 months' --keygen
Why do you use such a value for SigningKeyLifetime when the default is 30 days already? You can just skip --signingkeylifetime and have medium term signing key valid for 30 days (1 month). I am not totally sure *1 months* is a valid argument here (could be, not sure) - why not the default 30 days or more than 1 month?
Your problem is kind of strange so need to make sure of some things, apologies in advance if the questions seam too obvious. Before answering to all these make sure you try without --signignkeylifetime or with other argument than *1 months* like 2 months, 6 months, 10 days, 30 days, etc.
- - path_to_my_master_key is the path to the folder containing a 'keys' subfolder which contains the ed25519_master_id_secret_key or (_encrypted)?
- - the user running the 'tor --keygen' command has read/write permissions to the targeted folder from --datadirectory?
- - is the date on the server where the 'tor --keygen' command runs correct?
- - fixing the permissions you mean changing the owner of the files to the user actually running the Tor daemon on your system? (debian-tor, _tor, etc.)
and uploading ed25519_signing_cert and ed25519_signing_secret_key and fixing the permission, Tor keep saying
Feb 03 07:27:40.000 [notice] It looks like I need to generate and sign a new medium-term signing key, because the one I have is expired. To do that, I need to load the permanent master identity key. Feb 03 07:27:40.000 [warn] We needed to load a secret key from /var/lib/tor/keys/ed25519_master_id_secret_key, but couldn't find it. Did you forget to copy it over when you copied the rest of the signing key material? Feb 03 07:27:40.000 [warn] Can't load master identity key; OfflineMasterKey is set. Feb 03 07:27:40.000 [err] Error initializing keys; exiting
That raises two questions to me: - why does Tor think the new keys are already expired? - why is Tor searching ed25519_master_id_secret_key? With OfflineMasterKey set it shouldn't care about the master secret key
It doesn't -- the only problem is that it warns when it shouldn't. Only a log message issue which is known and reported here:
https://trac.torproject.org/projects/tor/ticket/18133
Thank you, patacca
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
Thank you s7r for helping!
On 03/02/2016 17:53, s7r wrote:
Hello - see inline
On 2/3/2016 3:49 PM, Riccardo Mori wrote:
Hi everyone,
Two months ago I decided to try the new ed25519 key introduced in Tor 2.7 with OfflineMasterKey set so I can keep the master key in a different place and just upload the medium-term signing key every month. Last month everything went ok: I renewed the key and Tor accepted it. This time instead after generating the new signing key with
# tor --datadirectory path_to_my_master_key --signingkeylifetime '1 months' --keygen
Why do you use such a value for SigningKeyLifetime when the default is 30 days already? You can just skip --signingkeylifetime and have medium term signing key valid for 30 days (1 month). I am not totally sure *1 months* is a valid argument here (could be, not sure) - why not the default 30 days or more than 1 month?
I wasn't sure about the default value and in case that after an update the default value were changed mine would still be 1 month. Anyway there's no important reason.
In the two text files attached there's the history of the commands I typed (made with script), so if you want you can find more details there . I am going to reply to your question here anyway
- path_to_my_master_key is the path to the folder containing a
'keys' subfolder which contains the ed25519_master_id_secret_key or (_encrypted)?
- the user running the 'tor --keygen' command has read/write
permissions to the targeted folder from --datadirectory?
yes to both of them, the folder contains ed25519_master_id_secret_key_encrypted and ed25519_master_id_public_key
- is the date on the server where the 'tor --keygen' command runs
correct?
Yeah, the date is synchronized with ntp in both systems (the Tor node and my laptop that contains the master key), the only thing that could be an issue is that the two systems are on different time zones: one is UTC+1 and the other is CST (UTC-6)
- fixing the permissions you mean changing the owner of the files
to the user actually running the Tor daemon on your system? (debian-tor, _tor, etc.)
yes, it's debian-tor, Tor node is running on debian 8.3
Why do you use such a value for SigningKeyLifetime when the default is 30 days already? You can just skip --signingkeylifetime and have medium term signing key valid for 30 days (1 month). I am not totally sure *1 months* is a valid argument here (could be, not sure)
--signingkeylifetime '1 months'
is fine (tested), it is not the same as 30 days (by a few hours) but otherwise it is ok.
Two months ago I decided to try the new ed25519 key introduced in Tor 2.7 with OfflineMasterKey
great to see more people using/testing this feature.
That raises two questions to me:
- why does Tor think the new keys are already expired?
Did you manually verify the expire dates of the newly generated cert/key files?
See also: https://trac.torproject.org/projects/tor/ticket/18228
https://trac.torproject.org/projects/tor/ticket/18133#comment:3
Sharing your torrc config might help others reproduce your problem.
btw: consider doing less steps as root, it is not needed to generate keys or scp stuff as root
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On 04/02/2016 00:00, nusenu wrote:
Two months ago I decided to try the new ed25519 key introduced in Tor 2.7 with OfflineMasterKey
great to see more people using/testing this feature.
That raises two questions to me: - why does Tor think the new keys are already expired?
Did you manually verify the expire dates of the newly generated cert/key files?
See also: https://trac.torproject.org/projects/tor/ticket/18228
https://trac.torproject.org/projects/tor/ticket/18133#comment:3
Thanks, that helped a lot, I didn't know how to show the expire date of the certificate. It turned out it was an idiot mistake: I was copying the wrong certificate, the one expired instead of the newly generated one! It would have been much easier to debug knowing this from the start =)
tor-relays@lists.torproject.org
-
nusenu -
Riccardo Mori -
s7r