Hello Tor Developers,
I’d like to share a draft proposal for enhancing the privacy of Tor hidden services (.onion) through garlic-style routing. This idea is inspired by I2P’s garlic routing model and focuses exclusively on .onion services to avoid exit node issues and reduce network impact.
Garlic bundles: Multiple encrypted messages (“cloves”) per bundle, including real requests, dummy traffic, and optional instructions.
Traffic obfuscation: Mandatory cover traffic, randomized timing, and optional asymmetric send/receive circuits to reduce timing correlation.
Goals:
Increase resistance to traffic correlation attacks
Reduce website fingerprinting risk
Enhance end-to-end privacy for hidden services
Compatible with existing Tor hidden service architecture
Optional multipath routing for further anonymity
Backward-compatible: Clients and services without garlic routing continue using standard cells
I have attached a draft TIP-style document with full technical details, security analysis, and proposed implementation steps. I would greatly appreciate any feedback, comments, or suggestions from the Tor developer community.
Thank you for your time and consideration.
Best regards,
Kester Pembroke
# TIP: Tor Garlic Routing for .onion Services **Author:** Kester Pembroke **Date:** 2026-04-07 **Status:** Draft --- ## 1. Abstract This proposal introduces **garlic-style routing for Tor hidden services (.onion)**. By bundling multiple encrypted messages (“cloves”) into a single garlic bundle, and adding cover traffic and optional asymmetric circuits, the design aims to **resist traffic analysis, timing attacks, and website fingerprinting**, while keeping Tor browsing unchanged. This approach targets **.onion services only**, eliminating the need for exit nodes and keeping overhead manageable. --- ## 2. Motivation Tor hidden services are already more private than standard Tor browsing, but they remain vulnerable to: 1. **Traffic correlation attacks** by global passive adversaries 2. **Website fingerprinting** based on packet size and timing 3. **Long-term statistical analysis** to link clients to services By integrating **garlic-style message bundling**, we can: - Hide which messages are real versus decoys - Introduce timing obfuscation via bundled cloves - Separate sending and receiving tunnels for asymmetric traffic --- ## 3. Design ### 3.1 Garlic Bundles A **garlic bundle** contains multiple encrypted messages (“cloves”): - **Real cloves:** actual request/response - **Dummy cloves:** padding or decoy traffic - **Instruction cloves:** optional follow-up instructions, e.g., delay or reroute **Bundle structure:** ``` [Bundle Header] [Clove 1] → encrypted real request [Clove 2] → dummy traffic [Clove 3] → padding [Clove 4] → follow-up instructions ... [Bundle MAC] → integrity check ``` - Each clove is individually encrypted - Only intended recipient can decrypt relevant cloves --- ### 3.2 Circuit Modifications - Uses existing Tor hidden service circuits and rendezvous points - Bundles replace single-cell transmission - Optional: **asymmetric circuits** for sending vs. receiving to break timing correlation --- ### 3.3 Timing & Padding - Minimum transmission rate enforced to reduce traffic analysis - Dummy cloves ensure cover traffic even when idle - Randomized bundle sizes and timings prevent fingerprinting --- ### 3.4 Multipath Enhancements (Optional) - Cloves may be sent over multiple parallel circuits - Further reduces linkability between client and service --- ## 4. Security Analysis | Threat | Current Tor | Proposed Garlic Routing | Improvement | |--------|------------|-----------------------|-------------| | Traffic correlation | Moderate vulnerability | High resistance via dummy cloves & asymmetric tunnels | ✅ | | Website fingerprinting | Moderate vulnerability | Bundled & padded cloves obscure patterns | ✅ | | Timing attacks | Possible | Randomized delays & multipath | ✅ | | Exit node compromise | Yes (normal Tor) | Not applicable (.onion only) | ✅ | **Limitations:** - Increased latency - Higher bandwidth use due to decoys - Does not protect against compromised endpoints --- ## 5. Implementation Plan 1. Modify **onion service protocol** to support garlic bundles 2. Update Tor client to create/decrypt bundles 3. Add **cover traffic scheduler** 4. Test optional **asymmetric circuits** for traffic analysis resistance 5. Run simulation to measure latency, bandwidth, and anonymity gains --- ## 6. Deployment Considerations - Backward compatible: clients and services without garlic routing continue using standard cells - Gradual adoption possible - Focused exclusively on **hidden services** to minimize network impact --- ## 7. Conclusion Garlic routing for Tor .onion services provides **stronger resistance to traffic analysis and fingerprinting** without altering Tor’s core functionality for normal browsing. By leveraging decoys, padding, and bundled messages, hidden services gain substantial anonymity improvements while remaining practical for deployment. --- ## 8. References / Inspiration - I2P Garlic Routing: https://geti2p.net/en/docs/how/garlic - Tor Hidden Services Architecture: https://community.torproject.org/onion-services/
_______________________________________________ tor-dev mailing list -- tor-dev@xxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to tor-dev-leave@xxxxxxxxxxxxxxxxxxxx