Re: Link padding discussion

[Matej Pfajfar <badbytes@freehaven.net>]

Andrei,

I've read you proposal and I have some questions ... i've thought about
this for a bit but I warn you that I may be thick :)

OK so we'll consider link padding and connection padding (long range
dummies, whatever the correct way of calling it is) separately - the two
techniques guard against different types of attacks/adversaries.

We also assume that the OP->COR connection is padded (for now) to constant
bandwidth, with the possibility of that connection being fairly permanent
to make timing attacks more difficult. Several circuits can then be
multiplexed over that connection. The "constant" bandwidth can even be
made adaptive to make it less expensive but let's leave that for now (in
fact the problem of padding the OP->COR connection is then pretty similar
to the one of padding COR->COR connections isn't it?)
Is this the sort of thing you were assuming?

OK so you propose a discrete increase in bandwidth on the entire network
as soon as current bandwidth requirements are exceeded on any part
of the network.
I don't quite understand what sort of quantum of bandwidth we are talking
about. Users will have different bandwidth requirements and restricting
them all to say 56kb/s is perhaps not practical, when some are on 1gb/s
pipes. And as soon as we have different OP->COR bandwidths, we'll have to
use different "quanta" when increasing network bandwidth.
But then again, does this leak any more information? My first thought is
no - the attacker will (again) just know that a new connection is going
through and which COR it starts at.

Say a user has a 1mb/s OP->COR connection to some COR which it uses as
its
first hop. Assume that there is no real traffic on that connection (so all
padding gets killed at the COR). Now when we get a new circuit from
that user, we'll increase the bandwidth on the COR->COR connections and
the attacker will know that
some real traffic is now going through the connection. And he will be able
to perform an intersection attack and do traffic confirmation without even
compromising the first COR. If we don't leak this information the attacker
would have to compromise the COR to observe that a new circuit is being
established by the user.
Does this make sense?

How do you propose the network backs off from the extra padding when the
load decreases?
We also need to make sure that we prevent counting to infinity.

George - is your work available for reading yet (sorry if I've
missed a previous pointer to it)?

Think that's it for now.

Mat

Matej Pfajfar

GPG Public Keys @ http://matejpfajfar.co.uk/keys