Dark Web Name

Anatomy of an Onion Domain: v2 vs v3 Architecture

Onion addresses have evolved from version 2 (v2) to version 3 (v3), introducing significant cryptographic improvements. The most notable change is the length of the addresses. V2 addresses were 16 characters long, based on 1024-bit RSA keys and SHA-1 hashes. These addresses were deprecated in October 2021, making them unreachable with the release of Tor version 0.4.6.x.

In contrast, v3 onion addresses consist of 56 characters encoded in Base32. This encoding is derived from a 32-byte Ed25519 public key, a 2-byte checksum, and a 1-byte version number. The use of Ed25519 keys enhances security, as these keys are more resistant to cryptographic attacks and allow for faster signature verification compared to RSA keys.

The v3 architecture employs a unique feature: it utilizes key-blinded cryptography to generate a daily-rotated blinded public key. This process prevents distributed hash tables from tracking or logging active services. Each v3 address functions as a self-authenticating cryptographic public key, eliminating the need for the Internet Domain Name System (DNS) or certificate authorities.

If you are considering generating a custom or vanity v3 onion address, be aware that this requires specialized tools like mkp224o. These tools perform massively parallelized cryptographic computations to brute-force specific prefix combinations against the Ed25519 key space.

When configuring your onion service, ensure that the underlying Ed25519 keys do not contain torsion components. This validation step is critical to prevent attackers from generating multiple equivalent addresses that map to a single service. The transition from v2 to v3 represents a significant enhancement in the security and usability of onion services.

Deterministic vs. Vanity Onion Address Generation

Generating a vanity onion address involves creating a specific prefix for your v3 onion address. This process is significantly more complex than generating a standard address. V3 onion addresses consist of 56 characters encoded in Base32, derived from a 32-byte Ed25519 public key, a 2-byte checksum, and a 1-byte version number.

Vanity address generators utilize brute-force search algorithms to find the desired prefix. These tools require massively parallelized computations to explore the vast Ed25519 key space. The computational complexity of generating a custom prefix can be estimated using the formula (O(n^k)), where (n) is the number of possible characters in the prefix and (k) is the length of the desired prefix. For example, a prefix of 5 characters could take an impractical amount of time to generate, depending on the processing power available.

Using third-party generation tools introduces security risks. If you rely on an external service, you may expose your private key to potential theft. Always verify that the tool you use does not log or store any generated keys. Consider running trusted software locally to mitigate this risk.

When configuring your onion service, ensure that the Ed25519 keys do not contain torsion components. This validation is crucial to prevent attackers from generating multiple equivalent addresses that could map to a single service.

In summary, while vanity onion address generation can provide a personalized touch, it requires careful consideration of computational resources and security practices.

Technical Mechanics of Tor Hidden Service Discovery

The Tor network employs distributed hash tables (DHT) to resolve onion names for hidden services. This system allows clients to discover and connect to services without relying on traditional DNS. Instead, each v3 onion address functions as a self-authenticating cryptographic public key.

When a user wants to access an onion service, the Tor client first retrieves the hidden service descriptor from the DHT. This descriptor contains the service's introduction points and a blinded public key. The introduction points are specific Tor nodes that the service has chosen to facilitate connections. The use of introduction points allows the service to maintain its anonymity while facilitating communication.

A complete connection between a Tor client and an onion service is established through a 6-hop circuit. This includes a 3-hop client circuit to a rendezvous point and a 3-hop service circuit. This design preserves mutual location privacy, ensuring that neither party can ascertain the other's IP address.

Descriptors play a crucial role in this process. They contain essential information about the service, including its public key and introduction points. By utilizing a daily-rotated blinded public key, the architecture prevents hidden service directories from tracking or logging active services. This cryptographic technique enhances security by ensuring that the service's identity remains hidden throughout the connection process.

To ensure the integrity of the connection, the Tor software mandates that the underlying Ed25519 keys do not contain torsion components. This validation helps prevent attackers from generating multiple equivalent addresses mapping to a single service.

In summary, the Tor network’s use of DHT and key-blinded cryptography provides a secure and efficient method for discovering hidden services without revealing IP addresses. It is crucial to configure your onion service correctly to maintain anonymity and security.

DNS and .onion Names: Addressing Misconceptions

.onion names operate outside the traditional Domain Name System (DNS). Unlike standard domains, which rely on a hierarchical DNS structure managed by a network of servers, .onion addresses utilize the Tor protocol. This protocol acts as a pseudo-top-level domain, entirely managed through cryptographic routing.

Each .onion address is generated from a 32-byte Ed25519 public key, alongside a 2-byte checksum and a 1-byte version number. This results in a 56-character string encoded in Base32. The address itself serves as a self-authenticating cryptographic public key, eliminating the need for certificate authorities.

The architecture of Tor ensures that users can access these hidden services without exposing their IP addresses. When connecting to a .onion service, users do not rely on DNS queries. Instead, they interact with the Tor network, which uses distributed hash tables (DHT) to resolve .onion names. This system enhances privacy and security by preventing the tracking of service locations.

For example, when a user wants to connect to a hidden service, the Tor client retrieves a hidden service descriptor from the DHT. This descriptor includes the service's introduction points and a blinded public key, facilitating a secure connection without revealing the service's identity.

If you are configuring your onion service, be aware that the connection relies on a 6-hop circuit: three hops to a rendezvous point and three hops to the service itself. This design maintains mutual location privacy, ensuring that neither the client nor the service can determine each other's IP addresses.

Understanding these principles helps clarify the operational uniqueness of .onion names. They are not just alternative domain names but are integral to the security and anonymity that the Tor network provides.

Cryptographic Integrity and Private Key Management

Securing the private key associated with your onion service is crucial for maintaining its integrity and preventing unauthorized access. The private key comprises two essential files: hostname and hs_ed25519_secret_key. Here are detailed guidelines for managing these keys effectively.

File Permissions

Set strict file permissions for the private key files. Use the following commands to ensure only the owner has access:

chmod 600 hostname
chmod 600 hs_ed25519_secret_key

This configuration restricts read and write permissions to the owner only, minimizing the risk of unauthorized access.

Backup Strategies

Regularly back up your hostname and hs_ed25519_secret_key files. Store backups in a secure, encrypted location, away from the server running your onion service. Consider using tools like gpg for encryption:

gpg -c hs_ed25519_secret_key

This command will create an encrypted version of your private key. Ensure that you also securely store the passphrase used for encryption.

Mitigation Against Key Theft

To mitigate the risk of key theft, implement the following strategies:

• Use a Hardware Security Module (HSM): If possible, store your private keys in an HSM. This adds a layer of physical security.

• Regularly Rotate Keys: Periodically generating new keys can help minimize exposure if a key is compromised. Update your onion service descriptor accordingly.

• Monitor Access Logs: Keep an eye on access logs for any suspicious activity. Investigate any unauthorized access attempts immediately.

• Limit Server Exposure: Ensure that your onion service is only accessible through the Tor network. Avoid exposing your service's IP address by using a firewall to restrict incoming connections.

By following these guidelines, you can significantly enhance the security of your onion service's private key. Maintaining cryptographic integrity is essential for the continued operation and anonymity of your hidden service.

System Engineering Best Practices for Hosting Hidden Services

To effectively host hidden services on the Tor network, it is essential to configure both the Tor daemon (torrc) and your web server (Nginx or Apache) correctly. This will help prevent information leakage, clock skew, and side-channel attacks.

Tor Daemon Configuration (torrc)

1. HiddenServiceDir: Specify a secure directory for storing hidden service keys and descriptors.

   HiddenServiceDir /var/lib/tor/hidden_service/
   

2. HiddenServicePort: Map the hidden service port to the local web server port.

   HiddenServicePort 80 127.0.0.1:8080
   

3. Use v3 Addresses: Ensure you are using v3 onion addresses. They provide better security and are less susceptible to attacks than legacy v2 addresses, which were deprecated in October 2021.

4. Avoid Default Values: Change default settings to prevent attackers from exploiting well-known configurations.

5. Use ControlPort: Set up a control port for managing Tor more securely.

   ControlPort 9051
   

Web Server Configuration (Nginx/Apache)

1. Disable Server Tokens: Prevent the web server from disclosing version information.

   • For Nginx:

     server_tokens off;
     

   • For Apache:

     ServerTokens Prod
     

2. Implement Strict Content Security Policies: Configure Content Security Policy (CSP) headers to mitigate XSS attacks.

   add_header Content-Security-Policy "default-src 'self'";
   

3. Limit HTTP Methods: Restrict allowed HTTP methods to only those necessary for your application.

   limit_except GET POST { deny all; }
   

4. Prevent IP Leakage: Ensure that your web server does not log real IP addresses. Use the following logging settings:

   • For Nginx:

     access_log off;
     

   • For Apache:

     LogFormat "" 
     

Additional Security Practices

• Clock Synchronization: Use NTP with a secure time source to prevent clock skew, which can be exploited in timing attacks.

• Regularly Update Software: Keep your Tor daemon and web server up to date to protect against vulnerabilities.

• Monitor Logs: Regularly review logs for unusual activity or access attempts.

By implementing these configuration parameters and best practices, you can significantly enhance the security and reliability of your hidden services on the Tor network. Properly securing both the Tor daemon and the web server is critical for maintaining anonymity and protecting against various attack vectors.

Key Takeaways and Operational Summary

• Verify that your private key files use strict owner-only permissions.

• Restrict incoming server connections by routing everything through the Tor daemon.

• Maintain rigorous backups of your cryptographic credentials in encrypted storage.

• Keep your web server tokens disabled to prevent information disclosure.

Review the Topic Links 3.0 Onion guide to deepen your understanding of v3 architecture and network mechanics.