[tor-dev] wfpadtools: comments about primitives
Marc Juarez
Marc.JuarezMiro at esat.kuleuven.be
Fri May 30 16:05:25 UTC 2014
-----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-----
More information about the tor-dev
mailing list