Changes between Version 47 and Version 48 of TorWeeklyNews/2013/11


Ignore:
Timestamp:
Sep 17, 2013, 12:28:56 PM (6 years ago)
Author:
harmony
Comment:

proper speech marks

Legend:

Unmodified
Added
Removed
Modified
  • TorWeeklyNews/2013/11

    v47 v48  
    2020Another round of speculation regarding the attitude of state surveillance
    2121agencies towards the Tor network was provoked by a slide [XXX] featured in an
    22 edition of the Brazilian current-affairs show 'Fantástico', broadcast on
     22edition of the Brazilian current-affairs show ‘Fantástico’, broadcast on
    2323September 8th [XXX]. The slide, leaked as part of the ongoing Snowden
    2424disclosures, appeared to show a tab in the alleged GCHQ [XXX] FLYING PIG
    25 surveillance interface labelled 'Query QUICK ANT - Tor events QFD'. Users
     25surveillance interface labelled ‘Query QUICK ANT - Tor events QFD’. Users
    2626on Reddit [XXX] and Twitter [XXX] began to suggest possible attacks on Tor
    2727that might be managed through such an interface.
    2828
    2929Andrew Lewman posted an official response on the Tor Blog [XXX] in which
    30 he reiterated that "it's not clear what the NSA or GCHQ can or cannot do",
     30he reiterated that “it's not clear what the NSA or GCHQ can or cannot do”,
    3131and that well-known theoretical attacks against the Tor network are clearly
    3232described on the project's FAQ page [XXX].
    3333
    3434He further added that the tool in question was more likely to involve
    35 "some "Tor flow detector" scripts that let them pick Tor flows out of a
    36 set of flows they're looking at" than "anything to do with deanonymizing
     35“some “Tor flow detector” scripts that let them pick Tor flows out of a
     36set of flows they're looking at” than “anything to do with deanonymizing
    3737Tor users, except insofar as they might have traffic flows from both sides
    38 of the circuit in their database."
     38of the circuit in their database.
    3939
    4040Finally, he remarked that instead of engaging in speculation based on
    41 limited evidence, "we'd rather spend our time developing Tor and conducting
    42 research to make a better Tor."
     41limited evidence, we'd rather spend our time developing Tor and conducting
     42research to make a better Tor.
    4343
    4444 [XXX] https://people.torproject.org/~andrew/2013-09-10-quick-ant-tor-events-qfd.png
     
    5353----------------------------
    5454
    55 Leif Ryge pointed out [XXX] an issue with Tor's current 'entry guards'
     55Leif Ryge pointed out [XXX] an issue with Tor's current ‘entry guards’
    5656system, whereby connections entering Tor from different points on the
    5757same network could potentially be linked to an individual user based on
     
    5959constant for a period of 4-8 weeks [XXX].
    6060
    61 Leif suggested that "assuming this is an accurate assessment, wouldn't
     61Leif suggested that assuming this is an accurate assessment, wouldn't
    6262it make sense to maintain separate sets of entry guards for each network
    63 that the user connects from?"
     63that the user connects from?
    6464
    6565Nick Mathewson replied [XXX] with an acknowledgement of the problem and
    6666a number of reasons why simply generating separate sets of guards might
    67 also harm a user's anonymity: "You would *not*, for example, want to
     67also harm a user's anonymity: You would *not*, for example, want to
    6868maintain a different set of entry guards for every IP that you receive,
    6969since if you did, a hostile DHCP server could feed you new IPs until you
    7070picked a hostile guard. Similarly, if you are a busy traveller who changes
    7171your view of what network you are on hundreds or thousands of times, your
    72 chance of picking a hostile guard would rise accordingly." He also pointed
    73 out that "having a record in your state file of every network you have
    74 visited is not necessarily the best idea either."
     72chance of picking a hostile guard would rise accordingly. He also pointed
     73out that having a record in your state file of every network you have
     74visited is not necessarily the best idea either.
    7575
    7676Nick concluded by mentioning Roger Dingledine's proposal to lower the
    77 number of entry guards selected by a client to one only, "to avoid the
    78 property of letting guard choices identify Tor clients".
     77number of entry guards selected by a client to one only, to avoid the
     78property of letting guard choices identify Tor clients.
    7979
    8080 [XXX] https://lists.torproject.org/pipermail/tor-dev/2013-September/005423.html
     
    8787In response to some confusion on the part of relay operators over the
    8888apparently slow growth in the use of newly-established nodes by clients,
    89 Roger Dingledine posted on the Tor Blog [XXX] a detailed account of how
     89Roger Dingledine posted on the Tor Blog [XXX] a detailed account of how
    9090new relays, and the bandwidth they supply, are gradually integrated into
    9191the Tor network by directory authorities, bandwidth authorities, and clients
    92 themselves. Roger stressed that "the descriptions here are in part anecdotal".
    93 
    94 Roger described the four broad phases that define the development of a
     92themselves. Roger stressed that “the descriptions here are in part anecdotal”.
     93
     94Roger outlined the four broad phases that define the development of a
    9595relay within the network, and finished by offering a number of questions
    96 for further research, under a general rubric: "what do these phases look
    97 like with real-world data?" If you would like to contribute to the Tor
     96for further research, under a general rubric: what do these phases look
     97like with real-world data? If you would like to contribute to the Tor
    9898community's understanding of the interaction between individual relays
    9999and the network as a whole, please take a look both at the list of sample
    100 questions and at Tor's publicly-available archive of metrics data [XXX],
     100questions and at Tor's publicly-available archive of metrics data [XXX],
    101101and see what you can find!
    102102
     
    152152
    153153Christian Sturm then promptly announced the release of updated packages for
    154 NetBSD, DragonFly BSD, illumos, Minix, and "other systems potentially using
    155 pkgsrc" [XXX].
     154NetBSD, DragonFly BSD, illumos, Minix, and other systems potentially using
     155pkgsrc [XXX].
    156156
    157157 [XXX] http://lists.nycbug.org/pipermail/tor-bsd/2013-September/000044.html