-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 09/01/15 14:40, Yawning Angel wrote: > 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.
Thanks for the pointer to an excellent paper. The single-hop padding scheme I suggested is closer to CS-BuFLO than BuFLO: it operates over TCP, doesn't inject padding when the TCP connection is congested, and allows the initiator to decide when to close each hop of the circuit (similar to CS-BuFLO's early termination). > 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). Why do you need stupid amounts of buffering? Bursts of data from the application can be smoothed out by keeping a small buffer and making the application block until there's space in the buffer - as TCP does, for example. In general I don't see any need for a padding scheme to touch anything below the TLS layer, or buffer any more data at the endpoints or relays than is already buffered. > 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. I don't see why padding needs to make multiplexing more complicated. We already have logic for multiplexing circuits over a TLS connection. Padding cells don't behave any differently from data cells in terms of head-of-line blocking. > 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. Is it necessary to detect peers that aren't padding correctly? In adaptive padding, if a relay detects a gap in the incoming traffic along a circuit, it doesn't try to assign blame for the existence of the gap - it just fills it. Likewise for the single-hop padding scheme I suggested: each relay is responsible for normalising its output, not speculating about why its input was or wasn't normalised. Cheers, Michael -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEcBAEBCAAGBQJUvkW6AAoJEBEET9GfxSfMM0kIAISz9Kg4jKqaAlnui6eHFWz8 X/ApFiwlPHhEGGbb971LdCuY8O+ycz/wPLAL18UO9uMXUYDz5YF9iZyWFRHBlKB1 83qENqhm6WCJUqC00BVk5GjJ4tPEQ/BgwIZyz2ZEq1kfUdnSJoBib25sUPC2uU6r h8rM2mJXyXj/6BxnVYQB9TKMzPDjCebR32aMOXJjxymy0B4Y3zwtlIiJje/Sz77i YFdz3FdBQ1yoAyaTny2ww8cn8BQN0rieXZnfvG2Gq9rT8uFe84Z8zR3rz5O1fjgi 86tiX+TZbXImdsOO/sEOqaSO9kCsq37rfV2oslSGcWjxJUwUymInFSkrt52F4AU= =cKyL -----END PGP SIGNATURE----- _______________________________________________ tor-dev mailing list [email protected] https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
