procmem@riseup.net wrote:

Hi I was wondering what the mathematical probability of guessing an onion v3 address that is kept secret.

Or asked differently: what is the entropy of v3 addresses if an adversary decides to bruteforce the entire keyspace?

I am struggling to come up with a usecase for authenticated v3 services when keeping an address secret has the same effect and one can generate multiple addresses for the same server and share them with different entities.  The degraded usability of v3 auth services compared to v2 is the reason I'm asking.

The probability is so close to 0 that we can safely assume it's impossible. v2 addresses are 80 bit. v3 addresses are 256 bit. v3 addresses are whole ed25519 public keys base32 encoded with a checksum and .onion at the end.

Do not be confused in comparing 80 to 256 like "just little over 3 times stronger" because in cryptography the difference between 256 bit security vs 80 bit security is orders of magnitude greater.

2^80 = 1208925819614629174706176 vs 2^256 = 115792089237316195423570985008687907853269984665640564039457584 007913129639936

Bruteforcing the entire keyspace of ed25519 is not something industry standards consider practical in the real world now, or in the foreseeable future.

However, your point is not correct. Keeping the address secret does not have the same effect as authenticated v3. Authenticated v3 exist to eliminate the side risks where the v3 address is not guessed (brute forced) but accidentally (or intentionally) leaked. This can be due to human error, malware / spyware, bug in the software using the v3 address, other kind of trojan-type operation and tons of other possibilities. Of course one can argue that such threats as described above can also steal the auth credentials / cookie and have the same effect on authenticated v3, but it's at least an additional precaution.

Also, if you have multiple users, having one v3 address with authentication is much better than multiple addresses, for the following reasons: - easier management - easier to configure and easier to maintain the application behind it (web server or whatever it is) - less resources needed by the Tor daemon - less load on your guard(s) / bridge(s), thus more capacity and better experience for your clients / visitors (if you have multiple addresses you need to maintain active introduction point circuits for all of them, publish descriptors, etc.)

Many cons and no pro the way I see it.