On Thu, Mar 01, 2012 at 10:07:43AM -0500, Chris Wheeler wrote:
On Wed, Feb 29, 2012 at 4:17 PM, grarpamp grarp...@gmail.com wrote:
Though HS is more hops away, I doubt it would affect timing or byte
counting all that much.
It wouldn't.
That was my first thought too, but then what is
The main problem, besides the overhead, is that padding doesn't work
if an adversary can do something as trivial as very briefly delaying
It is too easy for an adversary to put a traffic signature on a
circuit in one place, and look for it elsewhere. If he owns, e.g., the
first node and any
On Wed, Feb 29, 2012 at 05:17:34AM -0500, grarpamp wrote:
The main problem, besides the overhead, is that padding doesn't work
if an adversary can do something as trivial as very briefly delaying
It is too easy for an adversary to put a traffic signature on a
circuit in one place, and look
It may take a while for a clientA to use said entry but when
they do it seems it would be quite easy to time/count correlate
or munge the HS traffic of clientA. And only require two nodes
(hs, entry) and no GPA taps to do so.
That's why guards were introduced: They will not completely
We did do a design that, if one had a scheme that was successful
against a passive attacker, would resist an active attacker. Though
providing provable guarantees against a class of active attacker, it
is not ready for primetime. See Preventing Active Timing Attacks in
Low-Latency Anonymous
On Mon, Feb 27, 2012 at 11:52:34AM +, b.g. white wrote:
We did do a design that, if one had a scheme that was successful
against a passive attacker, would resist an active attacker. Though
providing provable guarantees against a class of active attacker, it
is not ready for primetime. See
I'm confused. Did you mean that you can't get to the anonbib webpage?
The link you gave is the same as the one given on the anonbib page.
(I gave the anonbib location to point people at a place where they
might see lots of related papers by others and also to give in one
location citation two
To clarify, http://freehaven.net/anonbib/ would not load for me. The page
was blank. Nothing but white space. It's working now, must be something on
my end.
On Mon, Feb 27, 2012 at 3:07 PM, b.g. white bgw...@gmail.com wrote:
I'm confused. Did you mean that you can't get to the anonbib webpage?
Dr Fu,
About the paper you sent, particularly the section on the simulation
using continuous-time mix, by the looks of it much of your degradation came
from packets arriving in the wrong order. I know the TCP doesn't handle
this well natively but what if a wrapper was written? The TCP stream
Hi Chris,
On Sun, Feb 26, 2012 at 12:09 PM, Chris Wheeler grin...@gmail.com wrote:
Dr Fu,
About the paper you sent, particularly the section on the simulation
using continuous-time mix, by the looks of it much of your degradation came
from packets arriving in the wrong order. I know the TCP
Sorry, TCP over TCP is believed not a good idea in terms of performance.
On Sun, Feb 26, 2012 at 1:30 PM, Xinwen Fu xinwe...@gmail.com wrote:
Hi Chris,
On Sun, Feb 26, 2012 at 12:09 PM, Chris Wheeler grin...@gmail.com wrote:
Dr Fu,
About the paper you sent, particularly the section on
I imagine that you would only need to reorder packets end-to-end since
those are the points on the network where
a correlation attack compromises identity. If the packets being sent from a
public web server on the internet travel through the tor network in
a different order than they were seen
I have been reading a lot about end-to-end correlation attacks on tor. I am
writing a paper on the subject and have a question which I can't seem to
find an answer to. I understand these attacks rely on the attacker being
able to view the traffic of the first relay a client is connecting to and
Chris Wheeler, 25.02.2012 18:06:
I have been reading a lot about end-to-end correlation attacks on tor. I am
writing a paper on the subject and have a question which I can't seem to
find an answer to. I understand these attacks rely on the attacker being
able to view the traffic of the first
Chris,
An attack may only work under its own threat model (capabilities and
resources an adversary has). If entries and exit are all secure, some
correlation attacks may not work. However, if the adversary can still
observe (not need to compromise Tor routers) the traffic into and out of
entries
Joe, I don't think that the order that the packet are sent
and received from the exit relay really changes the ease of correlation,
since they will arrive to the other end of the network in the same order.
But maybe the middle relay could be the one who re-arranges the packets.
Delaying some and
On 2/25/2012 3:23 PM, Chris Wheeler wrote:
Joe, I don't think that the order that the packet are sent
and received from the exit relay really changes the ease of correlation,
since they will arrive to the other end of the network in the same order.
1st, thanks for reply. You misunderstood (I
That is a lot of thinking. Many of the problems have been discussed before.
If you look at the bibliography on mixes, there are a lot of discussions.
Here is one of my papers on mixes:
http://www.cs.uml.edu/~xinwenfu/paper/fu_icdcs05.pdf. An adversary may
choose different ways for correlation and
Here is a paper of mine on TCP Performance in Flow-Based Mix Networks:
http://www.cs.uml.edu/~xinwenfu/paper/MixPerf_Fu.pdf.
If you are interested in why Tor performance is still not super, you an
refer to http://www.cs.uml.edu/~xinwenfu/paper/IPDPS08_Fu.pdf.
There are many other brilliant works
19 matches
Mail list logo
