On Thu, 8 Jan 2015 03:25:52 -0800 Mike Perry <mikeperry@xxxxxxxxxxxxxx> wrote: > I am unfortunately not optimistic about simple low-overhead padding > being successful here. At the very least, this problem will require > something more like a congestion-sensitive "always pad if there is > spare capacity available to grow the CWIND, but no data". We have an > approximation of this defense, too, in the form of the "Basket" > pluggable transport: > https://lists.torproject.org/pipermail/tor-dev/2014-December/007977.html I believe most of BuFLO's shortcomings documented in Cai, X., Nithyanand, R., Johnson R., "New Approaches to Website Fingerprinting Defenses" 5.A. apply to the currently proposed defense, though some of the problems have been solved via CS-BuFLO/Basket. CS-BuFLO as implemented in Basket without application assistance (to terminate padding early) has an absolutely gargantuan amount of bandwidth overhead, and the smarter Basket variant that doesn't have stupid amounts of sender side buffering isn't portable (for the same reasons that the new KIST code isn't). > If the adversary is *also* capable of Guard node coercion/compromise, > then we also want something like "Basket" to pad all the way to the > middle node, but to accomplish that, we actually need fair end-to-end > flow control for clients (and by extension, a datagram/UDP transport). Indeed. This is something I'd consider fun, but is really hard to do correctly, since the CS part ideally should be global across all connections (Basket gets that for free since there's only one TCP connection per guard, and only one guard). > (Though also note: We should not need such end-to-end flow control to > use Adaptive Padding all the way to the middle node, because we can > approximate fairness using statistics and consensus load balancing > information). None of the schemes I've seen proposed so far fit well into Tor as it is now, due to the fact that multiple circuits are multiplexed over a single channel (that enforces in-order-reliable delivery semantics). HOL blocking is a thing that needs to be considered. Solving this undoubtedly has really interesting anonymity impacts that I haven't given much thought to. Another issue with all of the padding schemes that I currently don't have a solid suggestion for is how to actually detect malicious peers that don't pad/pad incorrectly. I know Marc Juarez is going to be systematically evaluating defenses as part of his research work, so perhaps he can provide more insight into algorithm selection. Regards, -- Yawning Angel
Attachment:
pgpb9kk5G6iEY.pgp
Description: OpenPGP digital signature
_______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev