[tor-dev] wfpadtools: comments about primitives

[Kevin P Dyer]

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?

-Kevin


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

> -----BEGIN PGP SIGNED MESSAGE-----
> 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
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.11 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQEcBAEBAgAGBQJTiKxFAAoJEGfJ5xfgazlxw70H/1EbzYOuhLwDe5xdLiz/Pn3z
> UrXV+GCPG+Wa3SiQOFqCqSKn9D/E0dwLLZKcG/zE9F8wZeSbtjlDIBn4NNUwMzz3
> XMfCHcohxLHtKFwhTncHkTvEn6ZI1IzAUn1wCHdNWVGoTfVVuY5RtNKF0F0IxBBf
> IE1mEFoM1wKzmQIFvB/MkPlLo65Ilhwv20GHgqGwDpKXYwBROBHR7CLn29oL/GB8
> lZWVm0ZeDB0wtqjdPqxh9g2nEoxQR83BzJHeos+fue1onnZw+L23gbzfIvznjuL5
> 47Yed3T4l1q1k1i56G96/CoBIFlBboKfz5WhJ0dnDz2p4s996BNNIazxNybenjU=
> =5LGv
> -----END PGP SIGNATURE-----
> _______________________________________________
> 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>