Re: [tor-dev] Reg : using the keep alive messages

ÂWhich is the relevant part of the that should I look into for injecting such cells in streams ?

Thanks

Sambuddho

On Thu, Jun 9, 2011 at 3:03 PM, Sambuddho Chakravarty <sc2516@xxxxxxxxxxxx> wrote:

Dear Roger
ÂThanks for your response. I read the spec document about the RELAY_DROP cells. You say that no one has understood the passive correlation attack to utilize the RELAY_DROP cells. I am however little curious to see if "moderate padding" (enough to not mess up QoS of various services) can be used to prevent some of the attacks that rely on parameters such as OWD , RTT and B/W variation to link relays that are being used in a circuit. I am curious from the practical point of view of exploring such padding to prevent our bandwidth based confirmation attack or the M&D attack (and its 2009 variant) .Â

Thanks
Sambuddho

On Thu, Jun 9, 2011 at 12:29 PM, Roger Dingledine <arma@xxxxxxx> wrote:

On Wed, Jun 08, 2011 at 08:11:58PM -0400, Sambuddho Chakravarty wrote:
> Hi All
> I read in the Tor design spec that Tor control protocol supports keepalive
> messages which could be used for link padding . I wonder if anyone has ever
> explored using them...

I don't think you mean the Tor control protocol. There's no need to pad
that connection (or if there is, you've screwed up badly somewhere else).

The Tor protocol supports PADDING cells -- see sec 3 of tor-spec.txt:

Â PADDING cells are currently used to implement connection keepalive.
Â If there is no other traffic, ORs and OPs send one another a PADDING
Â cell every few minutes.

There's also a DROP relay cell. While PADDING cells can only be sent to
the adjacent relay, the client can send DROP cells to any relay on her
circuit, and any relay on the circuit can inject DROP cells to the client.
See also sec 7.2 of tor-spec.

But that said, I think the answer to your question is no. AFAIK nobody
has understood passive correlation attacks well enough to get to the
"if I change the design like this, does the attack work less well"
research stage.

--Roger

_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev