Hi,
since tor 0.2.7.5 is apparently not very far [1] from being released I was wondering whether there is any documentation about the new offline master key functionality? (or is this undocumented because it is not considered for general use yet?)
tor v0.2.7.4-rc's manual has the following:
" SigningKeyLifetime N days|weeks|months
For how long should each Ed25519 signing key be valid? Tor uses a permanent master identity key that can be kept offline, and periodically generates new "signing" keys that it uses online. This option configures their lifetime. (Default: 30 days)
OfflineMasterKey 0|1
If non-zero, the Tor relay will never generate or load its master secret key. Instead, you’ll have to use "tor --keygen" to manage the master secret key. (Default: 0) "
but doesn't say anything about --keygen itself [2].
The 0.2.7.x mentions also a '--newpass' option that I wasn't able to find in the manpage:
" - Add a new OfflineMasterKey option to tell Tor never to try loading or generating a secret Ed25519 identity key. You can use this in combination with tor --keygen to manage offline and/or encrypted Ed25519 keys. Implements ticket 16944. - Add a --newpass option to allow changing or removing the passphrase of an encrypted key with tor --keygen. Implements part of ticket 16769. - On receiving a HUP signal, check to see whether the Ed25519 signing key has changed, and reload it if so. Closes ticket 16790. "
Can a tor operator use one offline master key for several relays (that are running at the same time) or is one master key required for every relay? (I assume the latter)
How does the process of renewing the signing keys look like?
According to the logs I assume simple run tor --keygen again and copy ed25519_signing_cert + ed25519_signing_secret_key to the relay's /keys folder
the logs say: "It looks like I need to generate and sign a new medium-term signing key, because you asked me to make one with --keygen. To do that, I need to load the permanent master identity key."
Does a tor operator has to SIGHUP a running tor instance after copying the new signing keys to the appropriate folder or will tor attempt to reload that file as soon as this signing key expires?
How can a tor relay op display a given signing key's expiry date?
Does using the offline master key functionality imply that the relay will only have an ed25519 and no RSA key?
Is the offline master key limited to ed25519 keys and useless while using ed25519 + RSA keys at the same time? (because the RSA key is not offline?)
thanks!
[1] https://lists.torproject.org/pipermail/tor-consensus-health/2015-November/00...
On Fri, Nov 13, 2015 at 1:51 PM, nusenu nusenu@openmailbox.org wrote:
Hi,
since tor 0.2.7.5 is apparently not very far [1] from being released I was wondering whether there is any documentation about the new offline master key functionality?
Hi! There's a draft faq at https://trac.torproject.org/projects/tor/ticket/17021
and a ticket to improve the documentation at https://trac.torproject.org/projects/tor/ticket/16645#comment:7
I hope that somebody can pick up writing this all up and/or reviewing what's there now to make sure that it's working and right?
peace,
since tor 0.2.7.5 is apparently not very far [1] from being released I was wondering whether there is any documentation about the new offline master key functionality?
Hi! There's a draft faq at https://trac.torproject.org/projects/tor/ticket/17021
and a ticket to improve the documentation at https://trac.torproject.org/projects/tor/ticket/16645#comment:7
I hope that somebody can pick up writing this all up and/or reviewing what's there now to make sure that it's working and right?
Hi, thanks for the pointers. Looks like s7r takes care of the "guide", but for starters I would already be happy if the basic tor cli switches would be in the man page.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On 11/13/2015 8:51 PM, nusenu wrote:
Hi,
since tor 0.2.7.5 is apparently not very far [1] from being released I was wondering whether there is any documentation about the new offline master key functionality? (or is this undocumented because it is not considered for general use yet?)
tor v0.2.7.4-rc's manual has the following:
" SigningKeyLifetime N days|weeks|months
For how long should each Ed25519 signing key be valid? Tor uses a permanent master identity key that can be kept offline, and periodically generates new "signing" keys that it uses online. This option configures their lifetime. (Default: 30 days)
OfflineMasterKey 0|1
If non-zero, the Tor relay will never generate or load its master secret key. Instead, you’ll have to use "tor --keygen" to manage the master secret key. (Default: 0) "
but doesn't say anything about --keygen itself [2].
The 0.2.7.x mentions also a '--newpass' option that I wasn't able to find in the manpage:
" - Add a new OfflineMasterKey option to tell Tor never to try loading or generating a secret Ed25519 identity key. You can use this in combination with tor --keygen to manage offline and/or encrypted Ed25519 keys. Implements ticket 16944. - Add a --newpass option to allow changing or removing the passphrase of an encrypted key with tor --keygen. Implements part of ticket 16769. - On receiving a HUP signal, check to see whether the Ed25519 signing key has changed, and reload it if so. Closes ticket 16790. "
Can a tor operator use one offline master key for several relays (that are running at the same time) or is one master key required for every relay? (I assume the latter)
No. One unique master identity key per relay is required.
How does the process of renewing the signing keys look like?
According to the logs I assume simple run tor --keygen again and copy ed25519_signing_cert + ed25519_signing_secret_key to the relay's /keys folder
the logs say: "It looks like I need to generate and sign a new medium-term signing key, because you asked me to make one with --keygen. To do that, I need to load the permanent master identity key."
For renewing the medium term signing key and certificate, you need to have the master identity key accessible (either encrypted or unencrypted) and do:
$ tor --datadirectory /path/to/master_id_key --keygen
Tor will ask for the passphrase if the master id key is encrypted or just create the medium term signing key and certificate if it is not encrypted.
The above command will create the medium term signing key valid for the default lifetime of SigningKeyLifetime which is 30 days. If you want to specify a different lifetime you need to do:
$ tor --datadirectory /path/to/master_id_key --signingkeylifetime 'n days | weeks | months' --keygen
This requires the user running the commands to have write access in the directory where the master id key is, because the medium term signing key and certificate will be saved there. This is why we need the --master-key and --out arguments so we can use them in situations where the master id key is kept on a non-writeable media and tor should read from one place and write to another.
- --newpass is currently working and is intended to allow operators to encrypt/decrypt or change the passphrase of the master id key. If you want to encrypt, enter a passphrase and confirm it; if you want to decrypt, enter the current passphrase and NO new passphrase when asked.
Does a tor operator has to SIGHUP a running tor instance after copying the new signing keys to the appropriate folder or will tor attempt to reload that file as soon as this signing key expires?
Yes.
How can a tor relay op display a given signing key's expiry date?
I don't think there is an option for this.
Does using the offline master key functionality imply that the relay will only have an ed25519 and no RSA key?
For now, no, an online RSA key is needed otherwise the relay can't be part of the consensus. In time, when enough relays upgrade, RSA identity keys will be removed entirely.
Is the offline master key limited to ed25519 keys and useless while using ed25519 + RSA keys at the same time? (because the RSA key is not offline?)
Hmmm. Probably yes. Until transition (until we remove permanently RSA identities) only the ed25519 key will be protected, RSA key will have to be online. Even in this case, directory authorities remember relays by their ed25519 + RSA pair of identities. If just one of them changes, that relay will be rejected.
So if a relay that has the ed25519 identity offline has been compromised, the operator cannot reuse the ed25519 identity even this one is still considered safe. If the same ed25519 identity will appear again with a different RSA identity pair, it'll be rejected.
Is the offline master key limited to ed25519 keys and useless
while using ed25519 + RSA keys at the same time? (because the RSA key is not offline?)
Hmmm. Probably yes. Until transition (until we remove permanently RSA identities) only the ed25519 key will be protected, RSA key will have to be online. Even in this case, directory authorities remember relays by their ed25519 + RSA pair of identities. If just one of them changes, that relay will be rejected.
Ok, so I guess the only reason to use offline master keys now is to not have to start from scratch once RSA keys are deprecated for real.
thanks for your answers!
On 16 Nov 2015, at 04:51, nusenu nusenu@openmailbox.org wrote:
Is the offline master key limited to ed25519 keys and useless
while using ed25519 + RSA keys at the same time? (because the RSA key is not offline?)
Hmmm. Probably yes. Until transition (until we remove permanently RSA identities) only the ed25519 key will be protected, RSA key will have to be online. Even in this case, directory authorities remember relays by their ed25519 + RSA pair of identities. If just one of them changes, that relay will be rejected.
Ok, so I guess the only reason to use offline master keys now is to not have to start from scratch once RSA keys are deprecated for real.
A compromised relay's RSA key can't be used to run another relay without the corresponding offline ed25519 key. (I am assuming that a RSA key with a missing ed25519 key is treated the same as a RSA key with a different ed25519 key: the authorities reject the relay with the missing ed25519 key from the consensus.)
This is a good reason to use offline ed25519 master keys, which doesn't relay on RSA keys being deprecated/removed.
Tim (teor)
Is the offline master key limited to ed25519 keys and useless
while using ed25519 + RSA keys at the same time? (because the RSA key is not offline?)
Hmmm. Probably yes. Until transition (until we remove permanently RSA identities) only the ed25519 key will be protected, RSA key will have to be online. Even in this case, directory authorities remember relays by their ed25519 + RSA pair of identities. If just one of them changes, that relay will be rejected.
Ok, so I guess the only reason to use offline master keys now is to not have to start from scratch once RSA keys are deprecated for real.
A compromised relay's RSA key can't be used to run another relay without the corresponding offline ed25519 key. (I am assuming that a RSA key with a missing ed25519 key is treated the same as a RSA key with a different ed25519 key: the authorities reject the relay with the missing ed25519 key from the consensus.)
This is a good reason to use offline ed25519 master keys, which doesn't relay on RSA keys being deprecated/removed.
According to tor's changelog, key pinning is not enforced currently (changelog of 0.2.7.3-rc):
https://gitweb.torproject.org/tor.git/tree/ChangeLog?h=release-0.2.7#n89
On 16 Nov 2015, at 02:37, s7r s7r@sky-ip.org wrote:
Does a tor operator has to SIGHUP a running tor instance after copying the new signing keys to the appropriate folder or will tor attempt to reload that file as soon as this signing key expires?
Yes.
Yes, HUP?
Tim (teor)
Does a tor operator has to SIGHUP a running tor instance after copying the new signing keys to the appropriate folder or will tor attempt to reload that file as soon as this signing key expires?
Yes.
Yes, HUP?
reference: https://gitweb.torproject.org/tor.git/tree/ReleaseNotes?h=release-0.2.7#n86
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
Hi,
I have actually tried this in practice to see what happens.
If you replace the ed25519 medium term singing key and certificate in $datadirectory/keys, Tor will re-read keys from disk even if you don't send a SIGHUP when it outputs:
[notice] It looks like I should try to generate and sign a new medium-term signing key, because the one I have is going to expire soon. To do that, I'm going to have to try to load the permanent master identity key.
This message is repeated once every 30 seconds or so. When you send a SIGHUP, the reload happens instantly.
So, if an user correctly generates and provides the new medium term signing key and certificate and forgets to SIGHUP (reload), when the old key expires Tor won't exit. This is good.
On 11/19/2015 2:06 PM, nusenu wrote:
Does a tor operator has to SIGHUP a running tor instance after copying the new signing keys to the appropriate folder or will tor attempt to reload that file as soon as this signing key expires?
Yes.
Yes, HUP?
reference: https://gitweb.torproject.org/tor.git/tree/ReleaseNotes?h=release-0.2.7#n86
I have actually tried this in practice to see what happens.
If you replace the ed25519 medium term singing key and certificate in $datadirectory/keys, Tor will re-read keys from disk even if you don't send a SIGHUP when it outputs:
[notice] It looks like I should try to generate and sign a new medium-term signing key, because the one I have is going to expire soon. To do that, I'm going to have to try to load the permanent master identity key.
If that logentry is generated on a system with 'OfflineMasterKey 1' I would find it a bit misleading since it will never be able to load the permanent master key.
This message is repeated once every 30 seconds or so. When you send a SIGHUP, the reload happens instantly.
So, if an user correctly generates and provides the new medium term signing key and certificate and forgets to SIGHUP (reload), when the old key expires Tor won't exit. This is good.
Thanks for this info, so we don't have to do anything else than just replace the key files (no explicit SIGHUP needed) - and tor will read it when necessary. That is great since it makes key renewal idempotent out of the box.
How can a tor relay op display a given signing key's expiry date?
I don't think there is an option for this.
filed a ticket for it: https://trac.torproject.org/projects/tor/ticket/17639
Is there a custom openssl command to display the expiry date until this gets implemented in tor?
thanks!
On Thu, 19 Nov 2015 11:42:16 +0000 nusenu nusenu@openmailbox.org wrote:
How can a tor relay op display a given signing key's expiry date?
I don't think there is an option for this.
filed a ticket for it: https://trac.torproject.org/projects/tor/ticket/17639
Is there a custom openssl command to display the expiry date until this gets implemented in tor?
No. The on disk Ed25519 key format is custom to Tor, and the code doesn't use OpenSSL for any of the Ed25519 operations anyway.
Someone that wants to work on this should find the relevant data formats documented in prop 220.
Regards,
How can a tor relay op display a given signing key's expiry date?
I don't think there is an option for this.
filed a ticket for it: https://trac.torproject.org/projects/tor/ticket/17639
Is there a custom openssl command to display the expiry date until this gets implemented in tor?
No. The on disk Ed25519 key format is custom to Tor, and the code doesn't use OpenSSL for any of the Ed25519 operations anyway.
Someone that wants to work on this should find the relevant data formats documented in prop 220.
The spec [1] does not mention the first 32 bytes (== ed25519v1-cert: type4 ==) but after them it is fine.
if anyone else needs a quick'n dirty solution: python import time f = open('ed25519_signing_cert','rb') x = f.read() time.ctime(int(x[35:38].encode('hex'),16)*3600) 'Sat Dec 19 02:00:00 2015'
[1] https://gitweb.torproject.org/torspec.git/tree/proposals/220-ecc-id-keys.txt...