Several issues were present:
1) Firewall was too restrictive preventing connections to a necessary port (53, for local dns resolving)
2) Torrc misconfiguration. Not entirely sure which option.
3) Network interface misconfiguration, preventing connections to the IP for was set to use (server had 2 ipv4 ips and /64 block of ipv6
4) Bad cached certs
I don't know if it is strictly necessary, for me it works with these permissions:
700 (or drwx------) for the folder (folder2 in your case)
600 (or -rw-------) for the private_key file.
Both owned by the user and group that runs the tor process.
Yes it is possible to use the same tor process to serve a Hidden Server and as a client for accessing the Tor network. Just use the SocksListenAddress you have configured in the config file.
I'm not clear what you're asking. If you want to use the same private key as the Hidden Service address and the Identity Key for the Relay - this is a bad idea, as now ...
If you're doing something like a presentation, paper, book, etc, it's best to 1. Ask the developers and contributors directly https://www.torproject.org/contact/ and 2. Read the documentation for yourself.
So, you open the Tor browser and connect to your favorite website anonymously. Tor Browser reaches out to a guard node. The guard sends the browser its ...
As far as I remember shallot is used to generate custom keys and service names for version 2 of hidden services and you are requesting:
Remove the above mentioned line and it should work.
For version 3 name generation you can use mkp224o.
To my knowledge, there is currently no way to avoid that your key, at least for a short time, is on your server in cleartext.
However, the next generation onion services (V3) will allow you to do that once ticket #18098 (offline keys) has been implemented. Beware that the addresses differ from V2 addresses and you'll have to create a new onion address.
For any (sane) code, when you generate an RSA key you generate the private key then the public key is derived from it.
The onion address is the base32 encoded first 10 bytes of the sha1 sum of the asn1 encoded public key. So the private key derives directly to the public key and the address derives directly from the public key.
So, to ensure that the ...
It uses external libraries. Specifically OpenSSL, curve25519-donna, and ed25519 (either donna or ref10).
The code for key generation can be found in:
curve25519 - gitweb.torproject.org/tor.git/tree/src/common/crypto_curve25519.c?id=tor-0.2.7.6#n130
ed25519 - gitweb.torproject.org/tor.git/tree/src/common/crypto_ed25519.c?id=tor-0.2.7.6#n99
RSA - gitweb....
PREFIX/data/keys, where prefix is --prefix=xxx and in my case - I've made a double-precaution :
in torrc DataDirectory /usr/tor/data
and NO problem is given at all, I have ALL the keys in /usr/tor/data/keys
If you're not a relay and if you're not hosting a hidden service, then you can run multiple instances with exactly the same config.
If you are running a hidden service, then each introduction point will use the one that it heard about last. All instances should function though.
If you are running a relay, then each instance must have its own unique keys ...
As there are 32^16 possible addresses, such a collision is astronomically unlikely. In any case, there's no way of knowing if someone else has the same hidden service, just happens to be offline; there's no way of knowing whether another entity with the same HS key is actually you (from a previous session, or another machine etc).