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.
While I appreciate the initiative to secure Tor, this reeks of AI Slop.
There is no "full technical details" just a bunch of bullet points that are vague and lofty.
Please explain how you would both deliver "cloves" and maintain backwards compatibility with the standard 7 hop onion routing setup.
Regards,
Kester Pembroke via tor-dev:
···
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
_______________________________________________
tor-dev mailing list -- tor-dev@lists.torproject.org
To unsubscribe send an email to tor-dev-leave@lists.torproject.org