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
Hi, 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
participants (2)
-
Kester Pembroke -
tor@nullvoid.me