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.
Proposal Overview
-
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
Key Features
-
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 -- [email protected]
To unsubscribe send an email to [email protected]
