Re: [tor-dev] Should we disable the collection of some stats published in extra-infos?

[Karsten Loesing]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 15/01/16 23:00, Rob Jansen wrote:
> Hello,

Hi Rob,

I'm moving this discussion from metrics-team@ to tor-dev@, because I
think it's relevant for little-t-tor devs who are not subscribed to
metrics-team@.  Hope you don't mind.

> I was recently reviewing the statistics that Tor allows relays to
> collect and report to the dir servers [1], which then get published
> in extra-info documents [2]. Most of this can be enabled by simply
> setting a torrc option. There are quite a few statistics that I
> feel should not be collected. I'm wondering if the original purpose
> for collecting many of these statistics still exists, and if we
> still feel that the privacy compromises that were made when the
> collection was implemented are still valid in most cases.
> 
> Here are the stats I am most worried about, and why:
> 
> [unique ips per country code] *-ips (there are many of these, e.g.
> "entry-ips") Usually this involves storing individual user IP
> addresses in memory (in order to track uniqueness) over some period
> of time (usually 24 hours), sometimes for longer than the user
> would have otherwise been known to Tor (if a user's session is 1
> hour, Tor could remember the IP for at most 23 additional hours).
> This is reported, e.g., per entry; there are many cases in the data
> where it is very likely that only one user is connecting to a guard
> from a given country (because it is rounded up to 8). Users in
> small countries have the greatest risk (intersection attacks become
> really easy).

I agree that might just lose these statistics.  We used them in the
past as first approximation to counting users, but obviously that only
works as long as clients only connect to a single relay.  The only
place where we're still using them is in a workaround for estimating
bridge users.  See #15469 for more details and #8786 for something
we'd have to implement before taking these statistics out.

> [exit statistics by port number] exit-kibibytes-written 
> exit-kibibytes-read exit-streams-opened Tor is classifying its
> traffic into ports, which could uniquely identify the application
> being used by the client. They also track bandwidth usage per port
> (and per exit); again, this is bad for those using a random or
> unique looking ports (that a given exit does not see very often)
> because it could be used to create a fingerprint. Intersection
> attacks become easier with this information.

Agreed, I can see us dropping these statistics, too.  We're currently
not using them.  But also see my suggestion below.

> The less problematic stats:
> 
> [circuit-based cell statistics] cell-processed-cells 
> cell-queued-cells cell-time-in-queue cell-circuits-per-decile This
> provides queue timings and number of cells being processed at a
> relay. The number of cells can be used to compute bandwidth of
> circuits. It may be possible to launch some attacks that create
> several circuits with the intent of moving which decile buckets
> some legitimate circuits get placed into, but this is less
> worrisome of an attack than the others.

I'm less worried about this one.  But, suggestion below.

> Should Tor still be collecting these things? Should Tor disable the
> collection of these statistics until we have a more
> privacy-preserving way to collect and aggregate them?
> 
> The good news is that privacy-preserving techniques exist that can
> reduce information leakage. I'm developing a tool based on the
> secret-sharing variant of PrivEx [3] to collect some of these types
> of statistics while providing privacy guarantees. We are currently
> using it to collect only those stats that are useful for producing
> Tor traffic models. A great advantage of this tool is that the
> various counters that we store during the collection phase get
> noise added and are randomized during initialization; only the
> aggregates are ever known and revealed by the aggregation server,
> limiting the information that is lost if a relay is compromised.
> This is a large improvement over the current collection method,
> which only adds noise before publication and reveals statistics on
> a per-relay basis.

Suggestion: How about we evaluate these statistics published by relays
in the past years to see if there are other benefits or risks we
didn't think of, and then we decide whether to leave them in, modify
them, or take them out?

The reason is that I'd want to avoid removing this code only to
realize shortly after that we overlooked a good reason for keeping it.
 These statistics are being collected for years now, and it might take
another year or so for relays to upgrade to stop collecting them.  So
what's another month.

Thanks for (re-)starting this discussion!

> All the best, Rob

All the best,
Karsten


> [1] https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt [2]
> https://collector.torproject.org/recent/relay-descriptors/extra-infos/
>
> 
[3] 

[tor-dev] Is it possible to specify voluntary delays in my Tor client?

[Virgil Griffith]

I.e., if I want the extra resistance to traffic analysis that higher
latency connections provide, is there a way to specify that in my Tor
config?


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

Re: [tor-dev] Does Orbot use default obfs4 bridges?

[Nathan Freitas]

On Tue, Jan 19, 2016, at 03:33 PM, David Fifield wrote:
> On Tue, Jan 19, 2016 at 03:29:38PM -0500, Nathan Freitas wrote:
> > 
> > On Tue, Jan 19, 2016, at 02:52 PM, David Fifield wrote:
> > > Does Orbot have a list of default built-in obfs4 bridges? Or do users
> > > fetch them dynamically? I looked in the source code and found default
> > > meek bridges but not default obfs4.
> > 
> > No we have no default Obfs4 bridges built-in. It has been on my list to
> > get done, because we really should, obviously to make the user
> > experience better, and to alleviate meek traffic.
> > 
> > > I'm asking because we recently added a few new high-capacity default
> > > obfs4 bridges.
> > >   https://bugs.torproject.org/18071 (1 bridge)
> > >   https://bugs.torproject.org/18091 (2 bridges)
> > 
> > I will get this built-in ASAP.
> 
> The list of Tor Browser built-in bridges is here:
> https://gitweb.torproject.org/builders/tor-browser-bundle.git/tree/Bundle-Data/PTConfigs/bridge_prefs.js

Fantastic. Those will be built into the next release.
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Does Orbot use default obfs4 bridges?

[Nathan Freitas]

On Tue, Jan 19, 2016, at 02:52 PM, David Fifield wrote:
> Does Orbot have a list of default built-in obfs4 bridges? Or do users
> fetch them dynamically? I looked in the source code and found default
> meek bridges but not default obfs4.

No we have no default Obfs4 bridges built-in. It has been on my list to
get done, because we really should, obviously to make the user
experience better, and to alleviate meek traffic.

> I'm asking because we recently added a few new high-capacity default
> obfs4 bridges.
>   https://bugs.torproject.org/18071 (1 bridge)
>   https://bugs.torproject.org/18091 (2 bridges)

I will get this built-in ASAP.

+n
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Notes from 1st Tor proposal reading group [prop241, prop247, prop259]

[Mike Perry]

Paul and others: Here is the meetbot log from the meeting:
http://meetbot.debian.net/tor-dev/2016/tor-dev.2016-01-19-16.03.log.html

George and I also discussed RP and IP usage after the meeting as well. I
will be updating Prop#247 with that discussion.  I'll send a link when
I'm done. I may also work on txtorcon mockup of Prop#247 for testing,
but this may prove difficult due to control port limitations.

Isis will updating prop#259. We also generally agreed on merging #241
and #259, but I don't think anyone took that specific action item. Nick
offered to file tickets, though.

More replies below.

Paul Syverson:
> Hi George,
> 
> Crap. I missed this buried at the bottom of Nick's general
> announcement last Thursday about reviewing Tor Proposals (which was
> in my big backlog of threads to get to, and I did not notice its specific
> relevance to guards and onion services till I saw here).
> 
> When is the next one of these (guard proposals review discussion)? Are
> they listed on some general schedule somewhere? I see the reference to
> the little t-tor meeting tomorrow. (A) when is that? (B) Is there an
> agenda? Will the whole thing be devoted to discussing these three proposals?
> (I don't know if/when I can participate given other obligations
> but would like to know what when will be happening.)

Nick is sending the proposal review mails to this list. For the current
schedule, see:
https://lists.torproject.org/pipermail/tor-dev/2016-January/010219.html

The Tor meeting tomorrow is at 1330 UTC (==0830 am eastern). The agenda
is ticket dev progress updates, and then discussion. If you have
comments on the proposal updates, you can jump in during the discussion.


> aloha,
> Paul
> 
> 
> On Tue, Jan 19, 2016 at 10:41:23PM +0200, George Kadianakis wrote:
> > Today was the first Tor proposal reading group [0] and we discussed the
> > following guard proposals:
> > 
> >Prop#241: Resisting guard-turnover attacks [DRAFT]
> >Prop#259: New Guard Selection Behaviour [DRAFT]
> >Prop#247: Defending Against Guard Discovery Attacks using Vanguards 
> > [DRAFT]
> > 
> > In this mail, I will assume that the reader is familiar with the concepts
> > behind those proposals.
> > 
> > We started by discussing prop241 and prop259. These proposals specify how 
> > Tor
> > should pick and use entry guards.
> > 
> > - We decided that we should merge the remaining ideas of prop241 into 
> > prop259.
> > 
> > - prop259: The original guardset should also include 80/443 bridges 
> > (shouldn't
> >   have disjoint utopic/dystopic guard sets). We should specify a behavior on
> >   how the fascist firewall heuristic should work.
> > 
> > - prop259: Should probably not impose a specific data structure to the
> >   implementor except if strictly required. Instead maybe state the 
> > properties
> >   that such a data structure needs. Maybe we can put the hashring idea in 
> > the
> >   appendix?
> > 
> > - We can simulate the various algorithms we are examining to test their
> >   behavior and correctness.  Nick and Isis have already written some guard
> >   switching code to be simulated: 
> > https://github.com/isislovecruft/guardsim.git
> > 
> >   However, no simulations happen right now. We should code some simulation
> >   scenarios and check that the algorithm works as intended in all possible 
> > edge
> >   cases: 
> > https://github.com/isislovecruft/guardsim/blob/master/doc/stuff-to-test.txt
> > 
> > We then moved to discussing prop247. Proposal 247 specifies how entry guards
> > should be used by hidden services to avoid various attacks:
> > 
> > - We can think of prop241 as the proposal specifying how entry guards work 
> > on
> >   Tor. It specifies how Tor selects its set of guards and also how it picks 
> > and
> >   switches between them.
> > 
> >   Then prop247 could be stacked on top of prop241 specifying how entry 
> > guards
> >   are used specifically in _hidden services_ and describing how the 
> > guardsets
> >   from prop241 can be used in the hidden services setting.
> > 
> >   To achieve this design we should figure out what we need from Tor 
> > guardsets
> >   to achieve all the needs of prop247, and then we should design the 
> > interface
> >   of guardsets appropriately in prop241.
> > 
> >   A stupid Guardset interface that prop247 could use could be:
> > guardset_layer_1 = Guardset(nodes_to_consider, n_guards=1, 
> > rotation_period_max, flags, exclude_nodes)
> > guardset_layer_2 = Guardset(nodes_to_consider, n_guards=4, 
> > rotation_period_max, flags, exclude_nodes=guardset_layer_1)
> > 
> > - We discussed how the HS path selection should happen in prop247.
> > 
> >   Should layer-2 and layer-3 vanguards be picked from the set of Guard 
> > nodes,
> >   or should they be middle relays? This is important to figure out both for
> >   security and performance!
> > 
> >   Also, it's clear that layer-2 vanguards should not be the same node as the
> >   layer-1 guard. But 

[tor-dev] Notes from 1st Tor proposal reading group [prop241, prop247, prop259]

[George Kadianakis]

Today was the first Tor proposal reading group [0] and we discussed the
following guard proposals:

   Prop#241: Resisting guard-turnover attacks [DRAFT]
   Prop#259: New Guard Selection Behaviour [DRAFT]
   Prop#247: Defending Against Guard Discovery Attacks using Vanguards 
[DRAFT]

In this mail, I will assume that the reader is familiar with the concepts
behind those proposals.

We started by discussing prop241 and prop259. These proposals specify how Tor
should pick and use entry guards.

- We decided that we should merge the remaining ideas of prop241 into prop259.

- prop259: The original guardset should also include 80/443 bridges (shouldn't
  have disjoint utopic/dystopic guard sets). We should specify a behavior on
  how the fascist firewall heuristic should work.

- prop259: Should probably not impose a specific data structure to the
  implementor except if strictly required. Instead maybe state the properties
  that such a data structure needs. Maybe we can put the hashring idea in the
  appendix?

- We can simulate the various algorithms we are examining to test their
  behavior and correctness.  Nick and Isis have already written some guard
  switching code to be simulated: https://github.com/isislovecruft/guardsim.git

  However, no simulations happen right now. We should code some simulation
  scenarios and check that the algorithm works as intended in all possible edge
  cases: 
https://github.com/isislovecruft/guardsim/blob/master/doc/stuff-to-test.txt

We then moved to discussing prop247. Proposal 247 specifies how entry guards
should be used by hidden services to avoid various attacks:

- We can think of prop241 as the proposal specifying how entry guards work on
  Tor. It specifies how Tor selects its set of guards and also how it picks and
  switches between them.

  Then prop247 could be stacked on top of prop241 specifying how entry guards
  are used specifically in _hidden services_ and describing how the guardsets
  from prop241 can be used in the hidden services setting.

  To achieve this design we should figure out what we need from Tor guardsets
  to achieve all the needs of prop247, and then we should design the interface
  of guardsets appropriately in prop241.

  A stupid Guardset interface that prop247 could use could be:
guardset_layer_1 = Guardset(nodes_to_consider, n_guards=1, 
rotation_period_max, flags, exclude_nodes)
guardset_layer_2 = Guardset(nodes_to_consider, n_guards=4, 
rotation_period_max, flags, exclude_nodes=guardset_layer_1)

- We discussed how the HS path selection should happen in prop247.

  Should layer-2 and layer-3 vanguards be picked from the set of Guard nodes,
  or should they be middle relays? This is important to figure out both for
  security and performance!

  Also, it's clear that layer-2 vanguards should not be the same node as the
  layer-1 guard. But what about layer-3 vanguards? Can they be the same node as
  the layer-1 guard? If not, then an attacker learns information about the
  layer-1 guard by keeping track of the list of layer-3 vanguards by monitoring
  many layer-3 rotations.

  Also, should layer-3 guardsets share nodes between them or should they be
  disjoint?

  We should be very careful about what kind of relays we allow in each position
  since it's clear that it has security implications. We should edit the
  proposal and specify this further.

- We should test our design here with a txtorcon test client, and get some
  assurance about the performance and correctness of the system. Also, we need
  to see how CBT interacts with it.

If you want to help with any of the above, show up for the little-t-tor meeting
tomorrow.

---

[0]:  https://lists.torproject.org/pipermail/tor-dev/2016-January/010219.html
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] ENGINE_get_default_ECDx missing?

[rl1987]

Thanks, registered this patch in #17984.

2016-01-18 19:43, Gisle Vanem wrote:

Seems these two OpenSSL functions:
  ENGINE_get_default_ECDSA()
  ENGINE_get_default_ECDH()

have been dropped; in util/libeay32.num:
  ...
  ENGINE_get_default_ECDH 33871_1_0   NOEXIST::FUNCTION:
  ENGINE_get_default_ECDSA36621_1_0   NOEXIST::FUNCTION:
  ...

https://raw.githubusercontent.com/openssl/openssl/master/util/libeay.num

(not sure exactly what 'NOEXIST' does). So shouldn't common/crypto.c
be patched into something like:

--- a/src/common/crypto.c 2016-01-14 22:29:59
+++ b/src/common/crypto.c 2016-01-18 17:55:53
@@ -373,8 +373,10 @@
  used by Tor and the set of algorithms available in the engine 
*/

   log_engine("RSA", ENGINE_get_default_RSA());
   log_engine("DH", ENGINE_get_default_DH());
+#if OPENSSL_VERSION_NUMBER < OPENSSL_V_SERIES(1,1,0)
   log_engine("ECDH", ENGINE_get_default_ECDH());
   log_engine("ECDSA", ENGINE_get_default_ECDSA());
+#endif
   log_engine("RAND", ENGINE_get_default_RAND());
   log_engine("RAND (which we will not use)", 
ENGINE_get_default_RAND());

   log_engine("SHA1", ENGINE_get_digest_engine(NID_sha1));

Isn't OpenSSL 1.1.0 supported yet? Scratching head...

BTW, I'm using TDM-gcc 5.1 (http://tdm-gcc.tdragon.net/)
 on Win-10.


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

Re: [tor-dev] Does Orbot use default obfs4 bridges?

[David Fifield]

On Tue, Jan 19, 2016 at 03:29:38PM -0500, Nathan Freitas wrote:
> 
> On Tue, Jan 19, 2016, at 02:52 PM, David Fifield wrote:
> > Does Orbot have a list of default built-in obfs4 bridges? Or do users
> > fetch them dynamically? I looked in the source code and found default
> > meek bridges but not default obfs4.
> 
> No we have no default Obfs4 bridges built-in. It has been on my list to
> get done, because we really should, obviously to make the user
> experience better, and to alleviate meek traffic.
> 
> > I'm asking because we recently added a few new high-capacity default
> > obfs4 bridges.
> > https://bugs.torproject.org/18071 (1 bridge)
> > https://bugs.torproject.org/18091 (2 bridges)
> 
> I will get this built-in ASAP.

The list of Tor Browser built-in bridges is here:
https://gitweb.torproject.org/builders/tor-browser-bundle.git/tree/Bundle-Data/PTConfigs/bridge_prefs.js
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Notes from 1st Tor proposal reading group [prop241, prop247, prop259]

[Paul Syverson]

Hi George,

Crap. I missed this buried at the bottom of Nick's general
announcement last Thursday about reviewing Tor Proposals (which was
in my big backlog of threads to get to, and I did not notice its specific
relevance to guards and onion services till I saw here).

When is the next one of these (guard proposals review discussion)? Are
they listed on some general schedule somewhere? I see the reference to
the little t-tor meeting tomorrow. (A) when is that? (B) Is there an
agenda? Will the whole thing be devoted to discussing these three proposals?
(I don't know if/when I can participate given other obligations
but would like to know what when will be happening.)

aloha,
Paul


On Tue, Jan 19, 2016 at 10:41:23PM +0200, George Kadianakis wrote:
> Today was the first Tor proposal reading group [0] and we discussed the
> following guard proposals:
> 
>Prop#241: Resisting guard-turnover attacks [DRAFT]
>Prop#259: New Guard Selection Behaviour [DRAFT]
>Prop#247: Defending Against Guard Discovery Attacks using Vanguards 
> [DRAFT]
> 
> In this mail, I will assume that the reader is familiar with the concepts
> behind those proposals.
> 
> We started by discussing prop241 and prop259. These proposals specify how Tor
> should pick and use entry guards.
> 
> - We decided that we should merge the remaining ideas of prop241 into prop259.
> 
> - prop259: The original guardset should also include 80/443 bridges (shouldn't
>   have disjoint utopic/dystopic guard sets). We should specify a behavior on
>   how the fascist firewall heuristic should work.
> 
> - prop259: Should probably not impose a specific data structure to the
>   implementor except if strictly required. Instead maybe state the properties
>   that such a data structure needs. Maybe we can put the hashring idea in the
>   appendix?
> 
> - We can simulate the various algorithms we are examining to test their
>   behavior and correctness.  Nick and Isis have already written some guard
>   switching code to be simulated: 
> https://github.com/isislovecruft/guardsim.git
> 
>   However, no simulations happen right now. We should code some simulation
>   scenarios and check that the algorithm works as intended in all possible 
> edge
>   cases: 
> https://github.com/isislovecruft/guardsim/blob/master/doc/stuff-to-test.txt
> 
> We then moved to discussing prop247. Proposal 247 specifies how entry guards
> should be used by hidden services to avoid various attacks:
> 
> - We can think of prop241 as the proposal specifying how entry guards work on
>   Tor. It specifies how Tor selects its set of guards and also how it picks 
> and
>   switches between them.
> 
>   Then prop247 could be stacked on top of prop241 specifying how entry guards
>   are used specifically in _hidden services_ and describing how the guardsets
>   from prop241 can be used in the hidden services setting.
> 
>   To achieve this design we should figure out what we need from Tor guardsets
>   to achieve all the needs of prop247, and then we should design the interface
>   of guardsets appropriately in prop241.
> 
>   A stupid Guardset interface that prop247 could use could be:
> guardset_layer_1 = Guardset(nodes_to_consider, n_guards=1, 
> rotation_period_max, flags, exclude_nodes)
> guardset_layer_2 = Guardset(nodes_to_consider, n_guards=4, 
> rotation_period_max, flags, exclude_nodes=guardset_layer_1)
> 
> - We discussed how the HS path selection should happen in prop247.
> 
>   Should layer-2 and layer-3 vanguards be picked from the set of Guard nodes,
>   or should they be middle relays? This is important to figure out both for
>   security and performance!
> 
>   Also, it's clear that layer-2 vanguards should not be the same node as the
>   layer-1 guard. But what about layer-3 vanguards? Can they be the same node 
> as
>   the layer-1 guard? If not, then an attacker learns information about the
>   layer-1 guard by keeping track of the list of layer-3 vanguards by 
> monitoring
>   many layer-3 rotations.
> 
>   Also, should layer-3 guardsets share nodes between them or should they be
>   disjoint?
> 
>   We should be very careful about what kind of relays we allow in each 
> position
>   since it's clear that it has security implications. We should edit the
>   proposal and specify this further.
> 
> - We should test our design here with a txtorcon test client, and get some
>   assurance about the performance and correctness of the system. Also, we need
>   to see how CBT interacts with it.
> 
> If you want to help with any of the above, show up for the little-t-tor 
> meeting
> tomorrow.
> 
> ---
> 
> [0]:  https://lists.torproject.org/pipermail/tor-dev/2016-January/010219.html
> ___
> tor-dev mailing list
> tor-dev@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
___
tor-dev mailing list
tor-dev@lists.torproject.org

Re: [tor-dev] Does Orbot use default obfs4 bridges?

[isis]

David Fifield transcribed 0.5K bytes:
> Does Orbot have a list of default built-in obfs4 bridges? Or do users
> fetch them dynamically? I looked in the source code and found default
> meek bridges but not default obfs4.
> 
> I'm asking because we recently added a few new high-capacity default
> obfs4 bridges.
>   https://bugs.torproject.org/18071 (1 bridge)
>   https://bugs.torproject.org/18091 (2 bridges)

There's also https://bugs.torproject.org/18104 (1 bridge, identical to
#18071).  I'll have the patch up for that in five minutes.

-- 
 ♥Ⓐ isis agora lovecruft
_
OpenPGP: 4096R/0A6A58A14B5946ABDE18E207A3ADB67A2CDB8B35
Current Keys: https://blog.patternsinthevoid.net/isis.txt


signature.asc
Description: Digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

[tor-dev] Does Orbot use default obfs4 bridges?

[David Fifield]

Does Orbot have a list of default built-in obfs4 bridges? Or do users
fetch them dynamically? I looked in the source code and found default
meek bridges but not default obfs4.

I'm asking because we recently added a few new high-capacity default
obfs4 bridges.
https://bugs.torproject.org/18071 (1 bridge)
https://bugs.torproject.org/18091 (2 bridges)
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Notes from 1st Tor proposal reading group [prop241, prop247, prop259]

[Tim Wilson-Brown - teor]

> On 20 Jan 2016, at 07:41, George Kadianakis  wrote:
> 
> - prop259: The original guardset should also include 80/443 bridges (shouldn't
>  have disjoint utopic/dystopic guard sets). We should specify a behavior on
>  how the fascist firewall heuristic should work.

I wish I was there, but it was after midnight my time, so…

I'm currently working on #17840, which adds IPv6 client support to tor using 
the fascist firewall checks.
IPv6-only clients also have restricted guard choices, much like clients which 
can only use 80/443.
https://trac.torproject.org/projects/tor/ticket/17840

See also #17849, where yawning and I discuss logging a warning if clients have 
very restricted guard choices.
https://trac.torproject.org/projects/tor/ticket/17849

Tim

Tim Wilson-Brown (teor)

teor2345 at gmail dot com
PGP 968F094B

teor at blah dot im
OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Is it possible to specify voluntary delays in my Tor client?

[Virgil Griffith]

I understand that the original Tor model is to set low-latency and
low-jitter as a constraint as to permit things like interactive
web-browsing etc.  And yes, I presume Tor will always have this as a
constraint.

I am asking if:
(1) There currently exists some way I can specify in my torrc to
sacrifice some of these in exchange for a little greater anonymity
protection (say I want to slowly leak a file, etc.)

(2) If not, how difficult would be it to shoe-horn this into the
current tor model?  In short, if it's not too difficult, I can look
into finding funding it.

-V

On Wed, Jan 20, 2016 at 1:37 PM, grarpamp  wrote:
> On Tue, Jan 19, 2016 at 3:03 AM, Virgil Griffith  wrote:
>> I.e., if I want the extra resistance to traffic analysis that higher latency
>> connections provide, is there a way to specify that in my Tor config?
>
> Higher latency, in and of itself, does not provide any resistance to
> traffic analysis.
>
> https://en.wikipedia.org/wiki/Latency_(engineering)
>
> Higher global jitter might help, but circuit orientation at
> guards and exits through to the clients seems to nullify that.
>
> https://en.wikipedia.org/wiki/Jitter
>
> For which an idea may to become packet switching, which
> is really no longer Tor.
>
> https://en.wikipedia.org/wiki/Packet_switching
>
> Link padding seems the next real step but I've not put enough
> reading to it, only have idea to read about. Nor do I yet review about
> Tor padding proposal as sufficient or not, sorry.
>
> As it is not the Tor original model design maybe some other
> network will take this analysis / padding issue up before then.
> I've no idea.
> ___
> tor-dev mailing list
> tor-dev@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Is it possible to specify voluntary delays in my Tor client?

[grarpamp]

On Tue, Jan 19, 2016 at 3:03 AM, Virgil Griffith  wrote:
> I.e., if I want the extra resistance to traffic analysis that higher latency
> connections provide, is there a way to specify that in my Tor config?

Higher latency, in and of itself, does not provide any resistance to
traffic analysis.

https://en.wikipedia.org/wiki/Latency_(engineering)

Higher global jitter might help, but circuit orientation at
guards and exits through to the clients seems to nullify that.

https://en.wikipedia.org/wiki/Jitter

For which an idea may to become packet switching, which
is really no longer Tor.

https://en.wikipedia.org/wiki/Packet_switching

Link padding seems the next real step but I've not put enough
reading to it, only have idea to read about. Nor do I yet review about
Tor padding proposal as sufficient or not, sorry.

As it is not the Tor original model design maybe some other
network will take this analysis / padding issue up before then.
I've no idea.
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Proposals should have reviews. Let's make sure that happens. Here's a schedule.

[Nick Mathewson]

On Sun, Jan 17, 2016 at 8:39 PM, isis  wrote:
> Nick Mathewson transcribed 2.8K bytes:
>> Here's the schedule I have in mind for the  first meeting, based on
>> proposals already nominated at the IRC dev meeting.
>
> This idea and the schedule sound great to me.  (Minus that the HS devs should
> be at the HS one.)  Thanks, Nick!
>
> Side note: I've never understood the difference between [OPEN] and [ACCEPTED].
> xIs [OPEN] like "waiting for adoption"?
>

Rather than answer immediately, I'll send you towards proposal 001,
which is supposed to explain this kind of thing.  Please let me know
if it does a bad job explaining!  ;)

cheers,
-- 
Nick
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Revisiting Proposal 246: Merging Hidden Service Directories and Introduction Points

[David Goulet]

On 18 Jan (10:23:08), David Goulet wrote:
> On 16 Jan (16:21:30), John Brooks wrote:
> > 
> > > On Jan 16, 2016, at 4:52 AM, George Kadianakis  
> > > wrote:
> > > 
> > > Yes, I think I agree with this evaluation for now. Seems prop246 is more
> > > complicated than we can handle, and we should probably postpone it, 
> > > except if
> > > someone can analyze it well soon.
> > 
> > I agree. There are too many open questions with proposal 246 to plan on
> > implementing it in the same timeframe as we’re working on proposal 224.
> > 
> > I suggest we change the proposal status to ‘Needs-Research’, and plan to 
> > gather all
> > of these comments and make a real analysis of the tradeoffs at some later 
> > point.
> 
> I second that.
> 
> This thread outlines enough concerns to put this proposal back in
> research mode. Here is the commit torspec for that change. Please _NACK_
> if you are unhappy with it else in a day or so I'll push this.
> 
> https://gitweb.torproject.org/user/dgoulet/torspec.git/commit/?h=prop246-research=a4053594a34b141c5f05af54a7d15f1bf22952d9

I got a ACK from asn yesterday and no NACK.

This proposal is officially back in "Need-Research" status and this
email thread has been referenced in the proposal (like you can see in
the commit above). See torspec master:

commit a4053594a34b141c5f05af54a7d15f1bf22952d9

Cheers!
David

> 
> Cheers!
> David
> 
> > 
> > - special
> > 
> > ___
> > tor-dev mailing list
> > tor-dev@lists.torproject.org
> > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev



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



signature.asc
Description: Digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev