wfpadtools: comments about primitives
-----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-----
Marc Juarez <Marc.JuarezMiro@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.
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.)
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.
OK. You might want to write a small spec for your framing layer.
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.
Hm, by 'visit' you mean website visits? So your PT needs to know when you change websites? This is not supported at the moment. You can't even learn this information from within Tor, which is one layer closer to the browser than the PT. Why does BuFLO need to know about individual visits? Making PTs aware of website visits will require non-trivial changes to little-t-tor (and possibly implementation of proposal 196, etc.)
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?
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,
On Fri, 30 May 2014 17:42:39 +0100 George Kadianakis <desnacked@riseup.net> wrote:
Marc Juarez <Marc.JuarezMiro@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:
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/9fe9959c76c96ec3284f43c692cbb099230d... 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
-----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@riseup.net> wrote:
Marc Juarez <Marc.JuarezMiro@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:
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/9fe9959c76c96ec3284f43c692cbb099230d...
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-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi George, Thanks for your comments. On 05/30/2014 06:42 PM, George Kadianakis wrote:
Marc Juarez <Marc.JuarezMiro@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.
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.)
Oh, I see. That's why this module is not being used anywhere in obfsproxy. Thanks for letting me know.
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.
OK. You might want to write a small spec for your framing layer.
Yes, I have some diagrams for the message structure. Right now it's pretty simple, I just have a flag that indicates whether a message is padding or not. Though I think this structure will evolve a lot.
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.
Hm, by 'visit' you mean website visits? So your PT needs to know when you change websites? This is not supported at the moment. You can't even learn this information from within Tor, which is one layer closer to the browser than the PT.
Why does BuFLO need to know about individual visits?
Making PTs aware of website visits will require non-trivial changes to little-t-tor (and possibly implementation of proposal 196, etc.)
Yes, visits to webpages. I guess BuFLO does so to reduce the bandwidth overhead. In BuFLO there is also specified the minimum time for which we need to run the padding. This was directed to hide the real size of the page in case it is unusually small. However, when the page is sufficiently large to exceed the minimum time, it leaks information about the real size, and it has been shown that this can be exploited by an attacker. I have to think more about it but we might not need the limits of the visit. One possible approach could be to just fuzz these "page load boundaries" by looking at the bandwidth loads.
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?
Yes, you're right. However, I think we shouldn't overlap too much with Scramblesuit. I was thinking that Scramblesuit or obfs3 could be used together with this PT. Actually this is a question I wanted to ask you: can multiple PTs be used together? Except for the overhead of the protocol headers I don't see any technical limitation.
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,
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/ iQEcBAEBAgAGBQJTiNCHAAoJEGfJ5xfgazlxjYAH/297fIPaIaifZBimXbew6byh 9rImZPTiWv2r6bGTLKrAEQoipZ9W+1Sv62XLsT39szNBziZgv5lFIWZFd0L+2zDg 9PpLIsxsk/JuKBc/Di+WYnNgVaFcmZR3lkoOwnT73zjc34p/DmuQZXJfSqDCTiRj 8Tk36r287YhePNLUkeaegjAEjUphUG1Bouf5aSJO4kCWf1nIbos/OpJ212/HW3QV 7UPMV17XOtpai01B7WDhPs9e0LIf1AvoxZMH6X20ibOnOqpf1L4izGMYyGIQufvY xxoWQVxsha3kwmKJoQb3qRNMYs0UY/xLijYOPuofIPBqpFi5pV19CykKDPWU3CA= =OpDS -----END PGP SIGNATURE-----
On Fri, 30 May 2014 20:40:07 +0200 Marc Juarez <Marc.JuarezMiro@esat.kuleuven.be> wrote:
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?
Yes, you're right. However, I think we shouldn't overlap too much with Scramblesuit. I was thinking that Scramblesuit or obfs3 could be used together with this PT. Actually this is a question I wanted to ask you: can multiple PTs be used together? Except for the overhead of the protocol headers I don't see any technical limitation.
Not as well as we would like. Further improving our designs for combining PTs and adding an implementation is one of our GSOC projects this year though. My 0.02 dogecoin here would be to say "the PT combiner will fix it, so eventually we could do wfpadtools + obfs3/obfs4/scramblesuit/meek/fte and get the added defenses without (many? any?) code changes. Regards, -- Yawning Angel
Hi Marc, Thanks for doing this work, I'm excited to see what you learn this summer. However, I'm a bit confused by statements like: "The idea is to implement a set of primitives that any link padding-based defense would benefit [from]." Can you provide a high-level diagram that explains where your work will live in the network stack? (Doesn't need to be fancy, even a pencil+paper diagram scanned.) Specifically, is it your goal to build a link-padding PT that's composable with other PTs? -Kevin On Fri, May 30, 2014 at 9:05 AM, Marc Juarez < Marc.JuarezMiro@esat.kuleuven.be> wrote:
-----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----- _______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Kevin, Thanks for the comments :) I sketched a very simple diagram of the network stack. It lives in the same layer as the other PTs. The goal is not to build a PT that is composable with other PTs although, as I was discussing with Yawning and George Kadianakis in the other emails, it will probably need to be used on top of an obfuscation PT like Scramblesuit or obfs3. The goal is to, whenever there is a consensus in which specific Website Fingerprinting defense should be implemented in Tor (which is likely to be based on link padding), the developers of the countermeasure would just need to extend the classes of this PT to easily implement the defense. And that would be independently on the specific strategy of this final defense. On 05/30/2014 06:45 PM, Kevin P Dyer wrote:
Hi Marc,
Thanks for doing this work, I'm excited to see what you learn this summer.
However, I'm a bit confused by statements like: "The idea is to implement a set of primitives that any link padding-based defense would benefit [from]."
Can you provide a high-level diagram that explains where your work will live in the network stack? (Doesn't need to be fancy, even a pencil+paper diagram scanned.) Specifically, is it your goal to build a link-padding PT that's composable with other PTs?
-Kevin
On Fri, May 30, 2014 at 9:05 AM, Marc Juarez < Marc.JuarezMiro@esat.kuleuven.be> wrote:
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,
_______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
_______________________________________________ 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/ iQEcBAEBAgAGBQJTiNwTAAoJEGfJ5xfgazlxcs0H/1twC35eBk+cYd623PvGv+si ck8M2fYLOkmuk96u53b7x2zKMK0YbLeWzBVBsOtYJqm4FN7ML7gwhiXd3CezdHuQ Ex+AEpfQdxxAyJySOwM62OUwxirRjppXRSEPxnQXb6QPZHHiFMS55HhEyvyZvvWL VoYpiG4Ojy6oMoFcuCWcQCrASNDjIKlpYlGxHhQyJUvF1V/ZHUnhEzzWDTwWIz3g OxAv8Ttb0dNXf2f9irnKD3ZX+CPoMHfzpWhFmH/gwbp/OgTP81GqBMoRkGb4rDGa ucszS9M2ig8F7Jd7rQdxWxJDAgcuK2Ak2zMnTlIJ8L/aJYZXqb2BBWoXDtqU/Ao= =HJTs -----END PGP SIGNATURE-----
participants (4)
-
George Kadianakis -
Kevin P Dyer -
Marc Juarez -
Yawning Angel