[tor-dev] Setting NumEntryGuards=2

grarpamp grarpamp at gmail.com
Thu Mar 22 19:27:29 UTC 2018

On Thu, Mar 22, 2018 at 1:13 PM, Mike Perry <mikeperry at torproject.org> wrote:
> I strongly disagree. Dumping more traffic onto an already existing,
> otherwise in-use connection is not the same as the ability to force a
> new connection that is only used for a single request at a very specific
> time. These are completely different data retention resolutions, and
> if the netflow padding works as intended, dumping traffic onto an existing
> connection will be rolled up into all other traffic during that hour, or
> longer. At large scale, routers will likely be recording flows at just
> the connection level only, if that.
> What this means in practice is the ability for an adversary to go to
> large ISPs and say "Hey, give me connection logs you already have/can
> easily generate for these IPs during this specific time period" instead
> of "Hey, install this custom black box monitoring equipment for me and
> let me get arbitrary reports from it whenever I want". I know ISPs that
> have received and refused the black box request case because it was too
> intrusive. I also know ISPs that have given records over in the
> connection-level case.

Yes it's important to distinguish specific "netflow" style of records
analysis, from more general statistical traffic analysis of packets
flowing through a network, even if only from a limited to degenerate
number (2) of observation / targeting points. Even the simplest of
overlay networks could be considered at least a start against
the former. While the latter is a hard problem for nearly all of todays
networks and why few if any can claim to have resistance to anything
resembling GPA / GAA. Listing proposed solutions to the latter,
and why adoption of any of them into any overlay (or base layer)
network be it existing or new,  doesn't seem to really be happening
yet... a fine topic for another thread.

More information about the tor-dev mailing list