[tor-dev] wfpadtools: comments about primitives

[Yawning Angel]

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.

> [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.

> > 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,

-- 
Yawning Angel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20140530/304f45a9/attachment-0001.sig>