[tor-bugs] #17067 [Tor]: useful cover traffic

[Tor Bug Tracker & Wiki]

#17067: useful cover traffic
-------------------------+-----------------
     Reporter:  elypter  |      Owner:
         Type:  project  |     Status:  new
     Priority:  normal   |  Milestone:
    Component:  Tor      |    Version:
   Resolution:           |   Keywords:
Actual Points:           |  Parent ID:
       Points:           |
-------------------------+-----------------

Comment (by isis):

 Replying to [ticket:17067 elypter]:
 > if an adversary is sniffing between client and entry guard and between
 exit relay and destination server he can do traffic correlation in both
 directions.

 Sort of. I think you mean "traffic fingerprinting". Also, the
 effectiveness of traffic fingerprinting attacks are still currently
 debatable.

 > one way of hiding returning traffic could be to let the middle relay
 send cover traffic to lets say 5 random entry guards as soon as it
 recieves returning traffic. the entry guards send that traffic to one of
 their clients.

 Essentially, all relays talk to all other relays, all the time. A better
 specification of this idea is already contained within
 [https://gitweb.torproject.org/torspec.git/tree/proposals/254-padding-
 negotiation.txt proposal #254]. Please contribute further discussion of it
 to the author on [https://lists.torproject.org/pipermail/tor-
 dev/2015-September/009485.html the corresponding tor-dev mailing list
 thread].

 > the adversary would not be able to know who of the 6 people recieved
 data from that server. while still being a large amount of overhead its
 not as much as maxing out all connections.

 This is an insane amount of overheading, and again, I would direct you to
 the above-mentioned proposal for a better formulated design (also with
 significantly less overhead).

 > for sending traffic thats not as exit relays would have to send
 something to random servers.

 I am unable to parse what you meant in that sentence.

 > instead the client upload bandwidth could be reduced and the client
 could send constant low bandwith cover stream.

 Again, see proposal linked above.

 > this cover bandwidth could then be used for many useful things like:
 >
 > -provide a decentralized private cloud storage
 > -spread metadata and tor updates
 > -allow download content or embedded media on onion sites to be hosted in
 an anonymous high lattency p2p network
 > -website archive
 > -mail service

 ''wat''

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/17067#comment:1>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online