[tor-dev] wfpadtools: comments about primitives
Marc.JuarezMiro at esat.kuleuven.be
Fri May 30 19:04:36 UTC 2014
-----BEGIN PGP SIGNED MESSAGE-----
Yawning, thanks a lot for your comments.
On 05/30/2014 07:44 PM, Yawning Angel wrote:
> On Fri, 30 May 2014 17:42:39 +0100
> George Kadianakis <desnacked at riseup.net> wrote:
>> Marc Juarez <Marc.JuarezMiro at esat.kuleuven.be> writes:
>>> 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:
>>> 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
>>> 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).
>> Sounds reasonable.
>> (BTW, we recently found that scramblesuit's genDistribution() function
>> in probdist.py does not generate a uniform distribution. You can see
>> this, since the way the prob distr is generated, its first element has
>> a mean value of 1/2 instead of 1/n. Yawning fixed this in obfs4 I
>> think, but it remains unfixed in scramblesuit.)
> That's an example of how to make it uniform. I'm not sure which
> behavior is better, real world data on what the packet distribution of
> non-Tor network protocols look like on the wire would be useful here.
Oh, now I see. Anyway, the idea is to parametrize the probability
distributions, instead of just using uniform. I have to figure out how
to do that.
>>> 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.
>> In the end, I think this handshake will need to be confidential
>> (encrypted) somehow. Otherwise, the adversary could read the
>> probability distributions and unwrap your padding layer more
>> easily. Or is this not in your threat model?
> Likewise, however (correct me if I'm wrong), this is an orthogonal
> problem. The vision I have currently is, when when we do obfs6 or
> whatever, that we would come up with our own unique and clever way to
> handle authentication and confidentiality and use wfpadtools internally.
Yes, exactly. I guess this is a higher level discussion on where to use
wfpadtools, either as a stand-alone PT or included in an obfuscation
protocol... I'm not sure about this.
>>> 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.
> It's a shame that SIOCOUTQ isn't portable, because checking the send
> socket buffer's size is one of the better ways to do this.
> tor-dev mailing list
> tor-dev at lists.torproject.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
-----END PGP SIGNATURE-----
More information about the tor-dev