[tor-dev] wfpadtools: comments about primitives

[Marc Juarez]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Kevin,

Thanks for the comments :) I sketched a very simple diagram of the
network stack. It lives in the same layer as the other PTs. The goal is
not to build a PT that is composable with other PTs although, as I was
discussing with Yawning and George Kadianakis in the other emails, it
will probably need to be used on top of an obfuscation PT like
Scramblesuit or obfs3.

The goal is to, whenever there is a consensus in which specific Website
Fingerprinting defense should be implemented in Tor (which is likely to
be based on link padding), the developers of the countermeasure would
just need to extend the classes of this PT to easily implement the
defense. And that would be independently on the specific strategy of
this final defense.


On 05/30/2014 06:45 PM, Kevin P Dyer wrote:
> 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:
> 
> 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,
>> _______________________________________________
>> tor-dev mailing list
>> tor-dev at lists.torproject.org
>> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
>>
> 
> 
> 
> _______________________________________________
> tor-dev mailing list
> tor-dev at lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJTiNwTAAoJEGfJ5xfgazlxcs0H/1twC35eBk+cYd623PvGv+si
ck8M2fYLOkmuk96u53b7x2zKMK0YbLeWzBVBsOtYJqm4FN7ML7gwhiXd3CezdHuQ
Ex+AEpfQdxxAyJySOwM62OUwxirRjppXRSEPxnQXb6QPZHHiFMS55HhEyvyZvvWL
VoYpiG4Ojy6oMoFcuCWcQCrASNDjIKlpYlGxHhQyJUvF1V/ZHUnhEzzWDTwWIz3g
OxAv8Ttb0dNXf2f9irnKD3ZX+CPoMHfzpWhFmH/gwbp/OgTP81GqBMoRkGb4rDGa
ucszS9M2ig8F7Jd7rQdxWxJDAgcuK2Ak2zMnTlIJ8L/aJYZXqb2BBWoXDtqU/Ao=
=HJTs
-----END PGP SIGNATURE-----
-------------- next part --------------
A non-text attachment was scrubbed...
Name: wfpad_stack.pdf
Type: application/pdf
Size: 16456 bytes
Desc: not available
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20140530/c9af7489/attachment-0001.pdf>