Hi,
is there a way to use tor --keygen non-interactively?
background: I might want to integrate offline master key functionality into ansible-relayor [1]. The basic idea is to generate the master keys on the ansible client and push only the required signing keys to the relays (master keys never touch the relay). Since every step should be automated, master keys will not be passphrase protected. I consider unprotected (no passphrase) offline master keys still a lot better than online master keys, but currently I don't know how to generate master keys without passphrase in an non-interactive way (--keygen asks for the passphrase when generating a new key).
If that is not possible (out of the box) yet, would you consider a feature request, lets call it '--nopass' that can be used with --keygen to generate new keys without passphrase? (a more general approach would probably be to have --passphrase <passprase> but doing so would potentially write your passphrase to your shell history file).
thanks!
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
The "Enter passphrase" request when manually calling --keygen is optional, not mandatory. If you just leave it blank and proceed it will just create an unencrypted master identity key.
On 11/14/2015 10:18 AM, nusenu wrote:
Hi,
is there a way to use tor --keygen non-interactively?
background: I might want to integrate offline master key functionality into ansible-relayor [1]. The basic idea is to generate the master keys on the ansible client and push only the required signing keys to the relays (master keys never touch the relay). Since every step should be automated, master keys will not be passphrase protected. I consider unprotected (no passphrase) offline master keys still a lot better than online master keys, but currently I don't know how to generate master keys without passphrase in an non-interactive way (--keygen asks for the passphrase when generating a new key).
If that is not possible (out of the box) yet, would you consider a feature request, lets call it '--nopass' that can be used with --keygen to generate new keys without passphrase? (a more general approach would probably be to have --passphrase <passprase> but doing so would potentially write your passphrase to your shell history file).
thanks!
s7r:
The "Enter passphrase" request when manually calling --keygen is optional, not mandatory. If you just leave it blank and proceed it will just create an unencrypted master identity key.
I know, but that requires someone to press enter (or a dirty expect script) if you want to run that non-interactively.
Something like --nopass would be appreciated (if not there yet?).
https://trac.torproject.org/projects/tor/ticket/17603
thanks!
Maybe:
echo "" | whatyouwanttodo --keygen
or
whatyouwanttodo --keygen < EOF
~Josef
Am 15.11.2015 um 16:26 schrieb nusenu:
s7r:
The "Enter passphrase" request when manually calling --keygen is optional, not mandatory. If you just leave it blank and proceed it will just create an unencrypted master identity key.
I know, but that requires someone to press enter (or a dirty expect script) if you want to run that non-interactively.
Something like --nopass would be appreciated (if not there yet?).
https://trac.torproject.org/projects/tor/ticket/17603
thanks! _______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
EOF is false of course. I mean < /dev/null of course :-)
Am 15.11.2015 um 16:28 schrieb Josef Stautner:
Maybe:
echo "" | whatyouwanttodo --keygen
or
whatyouwanttodo --keygen < EOF
~Josef
Am 15.11.2015 um 16:26 schrieb nusenu:
s7r:
The "Enter passphrase" request when manually calling --keygen is optional, not mandatory. If you just leave it blank and proceed it will just create an unencrypted master identity key.
I know, but that requires someone to press enter (or a dirty expect script) if you want to run that non-interactively.
Something like --nopass would be appreciated (if not there yet?).
https://trac.torproject.org/projects/tor/ticket/17603
thanks! _______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
On 16 Nov 2015, at 02:36, Josef Stautner hello@veloc1ty.de wrote:
EOF is false of course. I mean < /dev/null of course :-)
Am 15.11.2015 um 16:28 schrieb Josef Stautner: Maybe:
echo "" | whatyouwanttodo --keygen
or
whatyouwanttodo --keygen < EOF
These alternatives will produce different outputs:
The /dev/null alternative produces no input data. The echo "" alternative produces a newline on most platforms.
Consistent "no password" passwords are another reason to have a --no-pass option.
Tim (teor)
Maybe:
echo "" | whatyouwanttodo --keygen
or
whatyouwanttodo --keygen < EOF
Yes I tried that already, but no it does not work.
That would require the program (tor) to read from sdtin - which it doesn't.
solution: generate master keys non-interactively: tor --datadir data --orport 1234 --list-fingerprint
The "Enter passphrase" request when manually calling --keygen is optional, not mandatory. If you just leave it blank and proceed it will just create an unencrypted master identity key.
I know, but that requires someone to press enter (or a dirty expect script) if you want to run that non-interactively.
Something like --nopass would be appreciated (if not there yet?).
Maybe not using --keygen in the first place is the workaround here ;) (So I get master keys without passphrase and non-interactively)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
Oh, right - sorry, misunderstood.
In this case not using --keygen might be a workaround. I do understand the use of --nopass, I'll include it in the ticket and maybe we can have it along with --master-key and --out.
On 11/15/2015 5:36 PM, nusenu wrote:
The "Enter passphrase" request when manually calling --keygen is optional, not mandatory. If you just leave it blank and proceed it will just create an unencrypted master identity key.
I know, but that requires someone to press enter (or a dirty expect script) if you want to run that non-interactively.
Something like --nopass would be appreciated (if not there yet?).
Maybe not using --keygen in the first place is the workaround here ;) (So I get master keys without passphrase and non-interactively)
background: I might want to integrate offline master key functionality into ansible-relayor [1].
I added (preliminary) OfflineMasterKey support to ansible-relayor [1] - in fact it will become the only option eventually as it make many things actually simpler, would be great if someone could take a look and let me know whether it looks reasonable.
The security critical parts are probably - key generation [2] - copying of key material to the relay [3]
I copy/expose the following files to the relay:
[ 'ed25519_master_id_public_key', 'ed25519_signing_cert', 'ed25519_signing_secret_key', 'secret_id_key', 'secret_onion_key', 'secret_onion_key_ntor']
[1] https://github.com/nusenu/ansible-relayor/commit/2c4040df7848f382ced02b43f35... [2] https://github.com/nusenu/ansible-relayor/blob/2c4040df7848f382ced02b43f35ca... [3] https://github.com/nusenu/ansible-relayor/blob/2c4040df7848f382ced02b43f35ca...
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On 11/19/2015 12:19 AM, nusenu wrote:
background: I might want to integrate offline master key functionality into ansible-relayor [1].
I added (preliminary) OfflineMasterKey support to ansible-relayor [1] - in fact it will become the only option eventually as it make many things actually simpler, would be great if someone could take a look and let me know whether it looks reasonable.
The security critical parts are probably - key generation [2] - copying of key material to the relay [3]
I copy/expose the following files to the relay:
[ 'ed25519_master_id_public_key', 'ed25519_signing_cert', 'ed25519_signing_secret_key', 'secret_id_key', 'secret_onion_key', 'secret_onion_key_ntor']
When first setting up (new relay) or restoring the relay, yes. But when only renewing the ed25519 medium term signing key (if ansible-relayor will support this) you only need to copy/expose the following files to the relay:
ed25519_signing_cert, ed25519_signing_secret_key
If you also move secret_onion_key and secret_onion_key_ntor, it could mess Tor's internal automated key rotation, and the descriptors available to clients might become invalid, making it impossible for clients to extend circuits through this relay. That's why Tor keeps a .old version of these keys when rotating, so clients with older descriptors won't experience circuit failures when using this relay.
To detect this, either the user will let ansible-relayor know if he is setting up a new relay / restoring a relay or just renewing the ed25519 keys for a running relay, either read Tor's $datadirectory/keys folder and if secret_id_key exists, assume the latter.
[1] https://github.com/nusenu/ansible-relayor/commit/2c4040df7848f382ced02b43f35...
[2]
https://github.com/nusenu/ansible-relayor/blob/2c4040df7848f382ced02b43f35ca...
[3]
https://github.com/nusenu/ansible-relayor/blob/2c4040df7848f382ced02b43f35ca...
I copy/expose the following files to the relay:
[ 'ed25519_master_id_public_key', 'ed25519_signing_cert', 'ed25519_signing_secret_key', 'secret_id_key', 'secret_onion_key', 'secret_onion_key_ntor']
When first setting up (new relay) or restoring the relay, yes. But when only renewing the ed25519 medium term signing key (if ansible-relayor will support this) you only need to copy/expose the following files to the relay:
ed25519_signing_cert, ed25519_signing_secret_key
If you also move secret_onion_key and secret_onion_key_ntor, it could mess Tor's internal automated key rotation, and the descriptors available to clients might become invalid, making it impossible for clients to extend circuits through this relay. That's why Tor keeps a .old version of these keys when rotating, so clients with older descriptors won't experience circuit failures when using this relay.
To detect this, either the user will let ansible-relayor know if he is setting up a new relay / restoring a relay or just renewing the ed25519 keys for a running relay, either read Tor's $datadirectory/keys folder and if secret_id_key exists, assume the latter.
thanks for the feedback!
Are secret_onion_* files required at all when restoring a relay? (it doesn't look like it)
If you confirm that I would simply remove them from the list and never copy them over.
remaining with these files:
ed25519_master_id_public_key ed25519_signing_cert ed25519_signing_secret_key secret_id_key
(tor's manual page FILES section is not very verbose in that regard - unfortunately)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On 11/19/2015 6:02 PM, nusenu wrote:
thanks for the feedback!
Are secret_onion_* files required at all when restoring a relay? (it doesn't look like it)
If you confirm that I would simply remove them from the list and never copy them over.
remaining with these files:
ed25519_master_id_public_key ed25519_signing_cert ed25519_signing_secret_key secret_id_key
(tor's manual page FILES section is not very verbose in that regard
- unfortunately)
The secret_onion_* files are not required when restoring a relay, no.
Some suggestions:
- - don't copy the ed25519_master_id_public_key file. If it is missing, Tor will just compute it from the certificate and save it to disk. But, if by accident an user copies the medium term signing keys related to another relay, Tor will detect they don't match the ed25519_master_id_public_key file and exit.
- - when you run tor --orport [...] just to generate the keys in a non-interactive way, include a PublishServerDescriptor 0 in the command as well, send the log to /dev/null and terminate the process immediately. The descriptor will have to be published by the Tor process actually running the relay. If the master id private key is not encrypted, --keygen should be able to renew the medium term signing key in a non-interactive way. But it's not a big deal if you decide to do it with tor --orport [...] if it's easier for you this way.
- - make it as hard as you can for users to accidentally mix keys belonging to different relays. This will be a tough one.
Some suggestions:
- don't copy the ed25519_master_id_public_key file. If it is missing,
Tor will just compute it from the certificate and save it to disk. But, if by accident an user copies the medium term signing keys related to another relay, Tor will detect they don't match the ed25519_master_id_public_key file and exit.
I'm copying ed25519_master_id_public_key to the relay to get rid of the following [warn] level log entries:
[warn] No key found in .../keys/ed25519_master_id_secret_key or .../keys/ed25519_master_id_public_key. [warn] Master public key was absent; inferring from public key in signing certificate and saving to disk.
The goal was to reduce the noise at the warn log level.
- when you run tor --orport [...] just to generate the keys in a
non-interactive way, include a PublishServerDescriptor 0 in the command as well
added
, send the log to /dev/null
done [1]
and terminate the process immediately.
I'm using --list-fingerprint for that.
The descriptor will have to be published by the Tor
process actually running the relay. If the master id private key is not encrypted, --keygen should be able to renew the medium term signing key in a non-interactive way. But it's not a big deal if you decide to do it with tor --orport [...] if it's easier for you this way.
I can switch to --keygen if it generates RSA keys (as long as they are a requirement for a relay) as well and --no-pass is implemented, but I'm also fine with the current way to generate keys.
- make it as hard as you can for users to accidentally mix keys
belonging to different relays. This will be a tough one.
I'm aiming to add a check that aborts if a key is found more than once in ~/.tor/offlinemasterkeys.
thanks, nusenu
[1] https://github.com/nusenu/ansible-relayor/commit/43d52e995abf6b3a311984bd54a...
-
Josef Stautner -
nusenu -
s7r -
teor