[tor-dev] wfpadtools: comments about primitives

Kevin P Dyer kpdyer at gmail.com
Fri May 30 16:45:31 UTC 2014

Hi Marc,

Thanks for doing this work, I'm excited to see what you learn this summer.

However, I'm a bit confused by statements like: "The idea is to implement a
set of primitives that any link padding-based defense would benefit [from]."

Can you provide a high-level diagram that explains where your work will
live in the network stack? (Doesn't need to be fancy, even a pencil+paper
diagram scanned.) Specifically, is it your goal to build a link-padding PT
that's composable with other PTs?


On Fri, May 30, 2014 at 9:05 AM, Marc Juarez <
Marc.JuarezMiro at esat.kuleuven.be> wrote:

> Hash: SHA1
> Hi all,
> I am a GSoC student working in a new PT for the development of future
> Website Fingerprinting countermeasures in Tor.
> The PT is not targeting any specific defense, but to link padding
> defenses in general. The idea is to implement a set of primitives that
> any link padding-based defense would benefit of.
> In this email I provide a more detailed description of these primitives
> and give a short update about their state. I forked the obfsproxy repo
> and made it publicly available in bitbucket:
> https://bitbucket.org/mjuarezm/obfsproxy-wfpadtools.
> I would appreciate comments from the Tor development community. I'm
> specially looking for advices that help me generalizing the padding
> module (padutils) and comments about the primitives I describe below.
> The envisaged primitives are:
> 1. A general padding class that provides methods to pad the link
> This part is almost finished. For that I reused the Scramblesuit's
> probdist and fifobuffer modules to buffer and flush data according to a
> given probability distribution.
> Using this class I have implemented a simple version of BuFLO (which is
> also included in the padutils module).
> 2. Create a framing layer for the PT
> This layer would allows to signal padding messages so that they can be
> filtered out. I have to implement the protocol's message scheme so I can
> parse the flags in the header and get rid of the padding messages.
> 3. Implement the state machine of the basic padding protocol.
> BuFLO assumes that there exists a mechanism to detect the beginning and
> end visits. I would implement this using a new state in the protocol's
> state machine (ST_VISITING), but I still need to find a way to signal
> the beginning and the end of each visit.
> 4. Implement the protocol's handshake.
> I took a look to the Scramblesuit's handshake.The handshake of this
> protocol would boil down to the negotiation of the parameters (e.g.,
> probability distributions) for the padding.
> 5. Implement a flow control protocol
> This would adjust the padding parameters while running. The fifobuffer
> we are currently using helps queuing the messages but we will need an
> extra logic to detect congestion.
> 6. Padding operations
> We will implement padding operations that might be handy for the future
> countermeasure. For example, one possible operation could be to specify
> the number of cells to send in response to a padding cell request.
> 7. A module to test protection against Website Fingerprinting
> This module would leverage the Peekaboo's framework by Dyer et al. (we
> may consider to extend it to include the newest Website Fingerprinting
> attacks).
> Best,
> - --
> marc
> Version: GnuPG v1.4.11 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
> iQEcBAEBAgAGBQJTiKxFAAoJEGfJ5xfgazlxw70H/1EbzYOuhLwDe5xdLiz/Pn3z
> UrXV+GCPG+Wa3SiQOFqCqSKn9D/E0dwLLZKcG/zE9F8wZeSbtjlDIBn4NNUwMzz3
> IE1mEFoM1wKzmQIFvB/MkPlLo65Ilhwv20GHgqGwDpKXYwBROBHR7CLn29oL/GB8
> lZWVm0ZeDB0wtqjdPqxh9g2nEoxQR83BzJHeos+fue1onnZw+L23gbzfIvznjuL5
> 47Yed3T4l1q1k1i56G96/CoBIFlBboKfz5WhJ0dnDz2p4s996BNNIazxNybenjU=
> =5LGv
> _______________________________________________
> tor-dev mailing list
> tor-dev at lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20140530/ef54210e/attachment.html>

More information about the tor-dev mailing list