[tor-dev] wfpadtools: comments about primitives

[Marc Juarez]

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

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:
>>>
>>> https://bitbucket.org/mjuarezm/obfsproxy-wfpadtools.
> 
> Excellent.
> 
>>> 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).
>>>
>>
>> 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.)
> 
> https://github.com/Yawning/obfs4/commit/9fe9959c76c96ec3284f43c692cbb099230dcb73
> 
> 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.


>> [snip]
>>> 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.
> 
> Regards,
> 
> 
> 
> _______________________________________________
> 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/

iQEcBAEBAgAGBQJTiNZEAAoJEGfJ5xfgazlxFRUIAK68pkmOGsyP6IgG79QwcKJr
WmJRBPc4XSelkRIDoxEEuivsU1/vErCKkzoZz+nat+Me6pzLK5Yz6tCqUx4v7PsY
JHctjOFAn3POCb+ZTgLyFpwEp0A1FP4gGmrSmAbJZNTaNj8/912kFXTfRdlctA8S
vi32zxfk3icxLe776wEuFc4cARav/ICszOH7RhDTGe0sX6Jd/mH8SiknRJZTA4/Q
QVytukCzZn8643xExPywdwvpmo7a7UUe3aBbCWY4+5R3gpX9+Im3QYwtKGZZ/Mtz
F5zyAdGs3kaL3McbpT1uhl4CeEL2+/LMcIz9AM+pdqEl5KWUTgNP4AfBmpwb5EA=
=w5ic
-----END PGP SIGNATURE-----