-----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 <desnac...@riseup.net> wrote: >> Marc Juarez <marc.juarezm...@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@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----- _______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev