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 ...
secret_id_key is an RSA key and ed25519_master_id_key is a Ed25519 key used for Hidden Services v3.
Here is what the spec says about it: https://gitweb.torproject.org/torspec.git/tree/rend-spec-v3.txt#n127
0.1. Improvements over previous versions.
Here is a list of improvements of this proposal over the legacy hidden
Better crypto (replaced SHA1/...
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 ...
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).
onion names are not based on DNS and don't work like them, but there are things that you can do.
Here is how I would do it. Just FYI, my example is based on Linux.
My website is simple. It is a simple http based site running on port 80. I enable and start apache on port 80 on my web server. I go to my cleanet dns provider and create an A record to point to ...
After looking into this again after leaving it for a long time, I quickly found the solution.
It turned out that the files in the /var/lib/tor/keys folder were not owned nor writable for the debian-tor user. Make sure to set debian-tor as the owner and allow this user to read and write the files.
chown -R debian-tor /var/lib/tor/keys/*
chmod 600 /var/lib/tor/...
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