Re: [tor-dev] How many exits exit from an IP address different than their OR address? (10.7%)

[Fabio Pietrosanti (naif) - lists]

On 1/12/16 4:43 AM, David Fifield wrote:
> I wanted to know how many exits exit from an address that is different
> from their OR address. The answer is about 10.7%, 109/1018 exits. The
> interesting part is that of those 109 mismatches, 87 have an exit
> address that differs from the OR address in all four octets; i.e., the
> IP addresses used by the exit are not even in the same /8.

It would be nice to prevent different IP traffic for Exit, unless
OutBoundBindAddress is defined and/or OutBoundExitAddress
(ie:https://trac.torproject.org/projects/tor/ticket/17975) is
implemented and defined.

>From a "transparency" point of view, i think that any routing aspects
shall stay into the consensus database, so that it could be checked for
possible sign of manipulations.

If someone want to do asymmetric routing, then that information must be
in the consensus (IMHO).


-- 
Fabio Pietrosanti (naif)
HERMES - Center for Transparency and Digital Human Rights
http://logioshermes.org - https://globaleaks.org - https://tor2web.org -
https://ahmia.fi
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Comparing Stem, metrics-lib, and zoossh

[Karsten Loesing]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 12/01/16 05:38, Damian Johnson wrote:
> Hi Karsten, implemented Stem counterparts of these (see attached).
> On one hand the code is delightfully simple, but on the other 
> measurements I got were quite a bit slower. Curious to see what
> you get when running at the same place you took your measurements.

Cool!  Here's a comparison between metrics-lib and Stem run on the
same system:

server-descriptors-2015-11.tar:
 - metrics-lib: 0.285430 ms
 - Stem: 1.02 ms (357%)

extra-infos-2015-11.tar:
 - metrics-lib: 0.215500 ms
 - Stem: 0.68 ms (316%)

consensuses-2015-11.tar:
 - metrics-lib: 246.713092 ms
 - Stem: 1393.10 ms (565%)

microdescs-2015-11.tar:
 - metrics-lib: 0.066566 ms
 - Stem: 0.66 ms (991%)

Do these Stem results look plausible?

Philipp, would you be able to write the Zoossh counterpart for the
descriptor types supported by it?  I'm even more curious now how those
numbers compare to metrics-lib and Stem.

All the best,
Karsten
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org

iQEcBAEBAgAGBQJWlLwCAAoJEJD5dJfVqbCr9y0H/i43rgx14dJXxxzUOnFLgUpm
THfWdWoWZQo1P5mQx5WZctUAjk1OBTGUX+EyVZzwOoLjaZHKXX8Nu14et1kz0CSM
K1qs0bDALgwXpVg5Rm79kIUanm0hcptWAlKkyqAu1X2Qfu/2fVKfCEvrDZJlVoCC
ePuMLLxvRim0fBT4K1aRKRdxwob4HKv90N+4Ib+Llw0CLy8DQFJjKKDpmruxxcuq
62KzWz2Ck2AiJUPr2BYMxFMozyE40lQ38RcP6rbomF2PxqxP2W5pjs9R0jfzcRA5
o28okykuFqaIp82rnuvmUXbYrYvPV/2GAqrsKAj+rHon/xeGDWsYZG/FOzIhZsU=
=soLz
-END PGP SIGNATURE-
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] How many exits exit from an IP address different than their OR address? (10.7%)

[Tim Wilson-Brown - teor]

> On 12 Jan 2016, at 21:01, Fabio Pietrosanti (naif) - lists 
>  wrote:
> 
> 
> 
> On 1/12/16 4:43 AM, David Fifield wrote:
>> I wanted to know how many exits exit from an address that is different
>> from their OR address. The answer is about 10.7%, 109/1018 exits. The
>> interesting part is that of those 109 mismatches, 87 have an exit
>> address that differs from the OR address in all four octets; i.e., the
>> IP addresses used by the exit are not even in the same /8.
> 
> It would be nice to prevent different IP traffic for Exit, unless
> OutBoundBindAddress is defined and/or OutBoundExitAddress
> (ie:https://trac.torproject.org/projects/tor/ticket/17975) is
> implemented and defined.

The current tor implementation simply calls connect() if OutBoundBindAddress is 
not set for the destination address family.
This means that the connection will be made from a source address based on the 
routing table entry for the destination address.
Tor really doesn't have much control over this, it's an OS-level decision.

We could set the default value of OutboundBindAddress(es) to the ORPort 
address(es), but this would override the OS's routing tables. I'm not sure this 
is a great idea on multi-homed hosts, as routing tables are typically set up 
for good reasons, and it would surprise operators to have them overridden. 
There would also be no way to switch this default off, and simply use the OS 
routing tables.

In other environments, the routing may be done at the VPS or ISP level, at 
which point tor can't even detect it without asking a (potentially unreliable) 
remote host.

Of course, if the operator specifically configures an outbound address, or an 
outbound address for Exit traffic (#17975), that's a different matter - tor 
should obey explicit configuration directives.

> From a "transparency" point of view, i think that any routing aspects
> shall stay into the consensus database, so that it could be checked for
> possible sign of manipulations.
> 
> If someone want to do asymmetric routing, then that information must be
> in the consensus (IMHO).


I'm not sure that adding "exit" IP addresses to the consensus is that helpful, 
given that:
* multi-homed hosts may have different exit IPs for different destinations or 
address families, and
* tor may not be able to detect which address(es) it is exiting from, or it may 
be an expensive or unreliable process.

But please feel free to submit a proposal to include exit IP addresses in the 
consensus - it would help if it included strategies to address these concerns.

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

[tor-dev] Proposal: Load Balancing with Overhead Parameters

[Mike Perry]

This proposal aims to allow us to load balance properly between Guard,
Middle, and Exit nodes with the addition of padding traffic to the
network.

Canonical proposal current lives in my load_balancing-squashed branch:
https://gitweb.torproject.org/user/mikeperry/torspec.git/tree/proposals/xxx-load-balancing-with-overhead.txt?h=load_balancing-squashed

Here is the text in-line, for ease of commenting on-list:

==

Filename: xxx-load-balancing-with-overhead.txt
Title: Load Balancing with Overhead Parameters
Authors: Mike Perry
Created: 01 January 2016
Status: Draft


0. Motivation

In order to properly load balance in the presence of padding and
non-negligible amounts of directory and hidden service traffic, the load
balancing equations in Section 3.8.3 of dir-spec.txt are in need of some
modifications.

In addition to supporting the idea of overhead, the load balancing
equations can also be simplified by treating Guard+Exit nodes as Exit
nodes in all cases. This causes the 9 sub-cases of the current load
balancing equations to consolidate into a single solution, which also
will greatly simplify the consensus process, and eliminate edge cases
such as #16255[1].


1. Overview

For padding overhead due to Proposals 251 and 254, and changes to hidden
service path selection in Proposal 247, it will be useful to be able to
specify a pair of parameters that represents the additional traffic
present on Guard and Middle nodes due to these changes.

The current load balancing equations unfortunately make this excessively
complicated. With overhead factors included, each of the 9 subcases goes
from being a short solution to over a page of calculations for each
subcase.

Moreover, out of 8751 hourly consensus documents produced in 2015[2],
only 78 of them had a non-zero weight for using Guard+Exit nodes in the
Guard position (weight Wgd), and most of those were well under 1%. The
highest weight for using Guard+Exits in the Guard position recorded in
2015 was 2.62% (on December 10th, 2015). This means clients that chose a
Guard node during that particular hour used only 2.62% of Guard+Exit
flagged nodes' bandwidth when performing a bandwidth-weighted Guard
selection. All clients that chose a Guard node during any other hour did
not consider Guard+Exit nodes at all as potential candidates for their
Guards.

This indicates that we can greatly simplify these load balancing
equations with little to no change in diversity to the network.


2. Simplified Load Balancing Equations

Recall that the point of the load balancing equations in section 3.8.3
of dir-spec.txt is to ensure that an equal amount of client traffic is
distributed between Guards, Middles, Exits, and Guard+Exits, where each
flag type can occupy one or more positions in a path. This allocation is
accomplished by solving a system of equations for weights for flag
position selection to ensure equal allocation of client traffic for each
position in a circuit.

If we ignore overhead for the moment and treat Guard+Exit nodes as Exit
nodes, then this allows the simplified system of equations to become:

  Wgg*G == M + Wme*E + Wmg*G# Guard position == middle position
  Wgg*G == Wee*E# Guard position == equals exit position
  Wmg*G + Wgg*G == G# Guard allocation weights sum to 1
  Wme*E + Wee*E == E# Exit allocation weights sum to 1

This system has four equations and four unknowns, and by transitivity we
ensure that allocated capacity for guard, middle, and exit positions are
all equal. Unlike the equations in 3.8.3 of dir-spec.txt, there are no
special cases to the solutions of these equations because there is no
shortage of constraints and no decision points for allocation based on
scarcity. Thus, there is only one solution. Using SymPy's symbolic
equation solver (see attached script) we obtain:

   E + G + M   E + G + M   2*E - G - M   2*G - E - M
  Wee: -, Wgg: -, Wme: ---, Wmg: 
  3*E 3*G  3*E   3*G

For the rest of the flags weights, we will do the following:

  Dual-flagged (Guard+Exit) nodes should be treated as Exits:
 Wgd = 0, Wmd = Wme, Wed = Wee

  Directory requests use middle weights:
 Wbd=Wmd, Wbg=Wmg, Wbe=Wme, Wbm=Wmm

  Handle bridges and strange exit policies:
 Wgm=Wgg, Wem=Wee, Weg=Wed

2.1. Checking for underflow and overflow

In the old load balancing equations, we required a case-by-case proof to
guard against overflow and underflow, and to decide what to do in the
event of various overflow and underflow conditions[3]. Even still, the
system proved fragile to changes, such as the implementation of Guard
uptime fractions[1].

Here, with the simplified equations, we can plainly see that the only
time that a negative weight can arise is in Wme and Wmg, when 2*E < G+M
or when 2*G < E+M. In other words, only when Exits or Guards are scarce.

Re: [tor-dev] Comparing Stem, metrics-lib, and zoossh

[Philipp Winter]

On Tue, Jan 12, 2016 at 09:40:35AM +0100, Karsten Loesing wrote:
> Philipp, would you be able to write the Zoossh counterpart for the
> descriptor types supported by it?  I'm even more curious now how those
> numbers compare to metrics-lib and Stem.

I'd love to, but I cannot promise when I'll be done with it :(

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

[tor-dev] Fwd: Orbot roadmap feedback

[Spencer]

Hi,

> 
> Nathan Freitas:
> I've got big plans for Orbot in 2016...
> any thoughts on the roadmap below:
>
> More Orbot VPN features including
> better UI for enabling/disabling
> Torouting,
> 

I love the animation when swapping identities but it is challenging to discover.

> 
> blocking specific apps, ports and/or
> hosts, and general
> 

It would be nice to have this in Orbot  instead of Privacy Guard, then it can 
also be more "network" centric.

> 
> "firewall" or little snitch type features 
> within the Orbot VPN
> 

Please yes with a firewall, though, outside applications over Tor, it seems 
that this would be best implemented at the exit routers.

> 
> OrbotShare: an OnionShare inspired file
> sharing and download manager
> service to enable easy hidden 
> service .onion setup and sharing
> (including support for new ephemeral
> onions)
>

Yes, please.  This could very well be the introduction point to Onion Services 
for many.

> 
> OrbotRelay/Bridge: improved UI for
> running a bridge or relay from
> within Orbot.
>

Yes, please.  Same introduction point as above.  In theory, a good interface is 
one that allows people to teach themselves.

>
> Creation of LibOrbot module/library for
> use by any app to embed Tor
> into their app
>

Yes, please.

> 
> Overall improved configuration / 
> settings UI to make tuning Orbot a
> better, simpler experience... this is an
> expansion of the new exit country 
> selector in Orbot v15.1, but also 
> includes managing things like
> network usage and so on.
>

Yes, please.  It would be great to select each node in a circuit in addition to 
*just* the country.

> 
> OrbotWear / OrbotTV
> 

Yes, please.

> 
> Some sort of "Pro" or Donation-ware
> version to allow a pay-what-you-can 
> concept
>

Separate versions for the rich and the poor?  You could do like LinkedIn and 
allow more functionality through paid version and charge those who need more 
security (;

Wordlife,
Spencer




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

Re: [tor-dev] How many exits exit from an IP address different than their OR address? (10.7%)

[coderman]

On 1/12/16, Tim Wilson-Brown - teor  wrote:
> ...
> The current tor implementation simply calls connect() if OutBoundBindAddress
> is not set for the destination address family.
> This means that the connection will be made from a source address based on
> the routing table entry for the destination address.
> Tor really doesn't have much control over this, it's an OS-level decision.

per https://trac.torproject.org/projects/tor/ticket/17975 however, it
might make sense to have a specific bind address for Exit traffic, in
addition to a general OutBoundBindAddress for OR-links. (as you allude
to below)



> We could set the default value of OutboundBindAddress(es) to the ORPort
> address(es), but this would override the OS's routing tables.

do NOT set a default for OutboundBindAddress !  it is intended as an
override, since the default behavior is usually desired and should be
kept as is.



> Of course, if the operator specifically configures an outbound address, or
> an outbound address for Exit traffic (#17975), that's a different matter -
> tor should obey explicit configuration directives.

this is the proper situation. only question is who would have a
compelling use for separating outbound OR connections and outbound
Exit traffic, as per #17975?


> I'm not sure that adding "exit" IP addresses to the consensus is that
> helpful, ...

do NOT ask for exit IP in consensus. it is not useful, not accurate,
wastes bandwidth, and fails in its intended purpose.


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

Re: [tor-dev] Propsal 263 Quantum-safe Hybrid handshake for Tor, updated feature request

[Nick Mathewson]

On Mon, Jan 11, 2016 at 9:16 AM, Zhenfei Zhang
 wrote:
> Hi list,
>
> Thanks for all your valuable comments.
> We have updated the feature request following your comments.
> Please see the attachment for the updated feature request, and see
> https://github.com/zhenfeizhang/ntru-tor/commit/0354fe1d61b2b79615301ff387e8c03230235f12
> for the modification over last version.
>
> Thanks for your time, and please let us know if you have any further
> comments/suggestions.
>

Thanks!  I've changed the file coding system to unix, fixed the
headers, and checked it in to the repository as the new version of
proposal 263.

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

[tor-dev] Needs Code Review: Shared Randomness Generation for Tor

[George Kadianakis]

Hello there,

we are happy to tell you that we finished coding proposal 250 and our first
attempt at implementation is ready for review.

You can find the final specification here:
 
https://gitweb.torproject.org/user/dgoulet/torspec.git/log/?h=prop250_final_v1
and the corresponding code here:
 https://gitweb.torproject.org/user/dgoulet/tor.git/log/?h=prop250_final_v1

Trac ticket #16943 (https://trac.torproject.org/projects/tor/ticket/16943) will
be used for code review. Please use this mailing list to discuss any issues
with the spec.

Some notes: We've separated this in 7 commits prefixed with prop250: except
first one that adds a needed tor_htonll/ntohll function to tor utils. This code
is mostly contained in two *new* files (with their headers) that are
shared-random.{c|h} and shared-random-state.{c|h}.

For what it's worth, we expect this code to run for a long time before the
shared random values generated by the authorities are used for anything
(e.g. HSDir scrambling).

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

[tor-dev] Fwd: Orbot roadmap feedback

[Nathan Freitas]

I've got big plans for Orbot in 2016... any thoughts on the roadmap
below, particularly how it aligns with Tor core roadmap, would be
appreciated.

- Original message -
From: Nathan of Guardian 
To: guardian-...@lists.mayfirst.org
Subject: Orbot roadmap feedback
Date: Mon, 11 Jan 2016 22:58:05 -0500


Here is my current set of brainstormed ideas for Orbot that I am
currently working through... please add, edit, improve and prioritize as
you are willing and able.

- Continued inclusion of the latest and greatest pluggable transports
(Obfs*, Meek, ???)

- Improved support for requesting and configuring Obfs4 bridges -
directly integrate with BridgeDB to provide streamlined way for people
to get bridges where Tor is blocked

- More Orbot VPN features including better UI for enabling/disabling Tor
routing, blocking specific apps, ports and/or hosts, and general
"firewall" or little snitch type features within the Orbot VPN

- OrbotShare: an OnionShare inspired file sharing and download manager
service to enable easy hidden service .onion setup and sharing
(including support for new ephemeral onions)

- OrbotRelay/Bridge: improved UI for running a bridge or relay from
within Orbot, including support for scheduled times (night only) or
states (only when plugged in, on wifi, and screen is off, etc)

- Removal of Polipo, in favor of new streamlined in process HTTP proxy
(less memory use, and more stable)

- Creation of LibOrbot module/library for use by any app to embed Tor
into their app

- Overall improved configuration / settings UI to make tuning Orbot a
better, simpler experience... this is an expansion of the new exit
country selector in Orbot v15.1, but also includes managing things like
network usage and so on.

- OrbotWear / OrbotTV: Should we expand Orbot support to other Android
platforms like watches and Smart TVs? Perhaps Orbot relay/bridge mode
could run on a TV or set top box?

- Some sort of "Pro" or Donation-ware version to allow a
pay-what-you-can concept within the app

Good, bad, ugly? Let me know!

-- 
  Nathan of Guardian
  nat...@guardianproject.info
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Fwd: Orbot roadmap feedback

[Georg Koppen]

Nathan Freitas:
> - Overall improved configuration / settings UI to make tuning Orbot a
> better, simpler experience... this is an expansion of the new exit
> country selector in Orbot v15.1, but also includes managing things like
> network usage and so on.

Could you explain that point a bit more, what you currently have and
what you plan to do? Especially the exit country selector seems kind of
scary to me but maybe I am just missing some bits. I looked at the
changelog you sent to tor-talk (in the alpha 1 release mail) but did not
find anything related.

Georg



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

Re: [tor-dev] Questions about censorship detection paper

[John]

Hi David,

Thank you, these pointers were very helpful. Do you know if there is
some kind of resource that lists known censorship events? I'd like to
see how good the approach from the paper does at identifying them.

--john


David Fifield:
> On Tue, Jan 12, 2016 at 07:21:39AM +, John wrote:
>> I ran into the technical report from George Danezis about an
>> anomaly-based censorship-detection system for Tor. I have a few
>> questions that I hope you can help me with.
>>
>> Is there an implementation available of the approach described in the paper?
> 
> Go to
>   https://metrics.torproject.org/userstats-relay-country.html
> and check "Show possible censorship events if available".
> 
> I think the source code is here:
> https://gitweb.torproject.org/karsten/metrics-web.git/tree/detector
> 
>> The paper talks about finding anomalies in the time series of the number
>> of requests to directory servers from certain jurisdictions. Where can I
>> find this data about the requests to directory servers?
> 
> https://collector.torproject.org/
> 
> I think you want the "dirreq-v3-reqs" lines. For example, here is a
> recently archived extra-info consensus:
> https://collector.torproject.org/recent/relay-descriptors/extra-infos/2016-01-12-07-05-27-extra-infos
> (The file will expire after a few days; after that go to
> https://collector.torproject.org/archive/relay-descriptors/extra-infos/.)
> 
> Here's a line from the file showing the number of requests by country
> for one of the relays:
> dirreq-v3-reqs 
> us=7808,ru=4400,de=4112,fr=2584,gb=1848,it=1352,es=1208,jp=1192,br=1184,nl=1024,ua=1008,ca=912,pl=728,au=696,md=680,in=584,se=464,ar=448,mx=448,id=384,be=336,at=320,tr=288,tw=288,ch=280,cz=264,il=264,kr=248,ir=240,th=232,kz=224,pt=224,gr=216,sg=216,fi=208,my=208,ro=192,dk=184,hu=176,ae=168,ve=168,by=160,cl=160,ie=160,vn=160,za=152,ph=144,no=136,co=128,hk=128,lv=128,nz=120,sk=120,bg=112,eg=112,pk=112,rs=104,bd=88,ma=80,ec=72,ng=72,dz=64,hr=64,pe=64,si=64,ee=56,lt=56,do=48,tn=48,az=40,ba=40,cr=40,is=40,jo=40,kw=40,qa=40,uy=40,af=32,am=32,bo=32,ci=32,cy=32,gh=32,gt=32,iq=32,ke=32,lu=32,pr=32,uz=32,et=24,ge=24,lb=24,mk=24,mn=24,sa=24,sd=24,sv=24,sy=24,tm=24,al=16,bh=16,bj=16,cu=16,gd=16,kg=16,kh=16,ly=16,ni=16,np=16,om=16,ps=16,re=16,sn=16,tt=16,??=8,ad=8,ao=8,as=8,aw=8,ax=8,bb=8,bf=8,bm=8,bn=8,bs=8,bw=8,cd=8,cg=8,cm=8,cn=8,cv=8,dm=8,gf=8,gm=8,gp=8,gq=8,gw=8,gy=8,hn=8,ht=8,im=8,jm=8,km=8,ky=8,li=8,lk=8,me=8,mg=8,mq=8,mr=8,mt=8,mu=8,mz=8,na=8,nc=8,ne=8,pa=8,pf=8,pg=8,pm=8
 ,
py=8,rw=8,sc=8,sm=8,sr=8,tj=8,tz=8,ug=8,vi=8,vu=8,ye=8,yt=8,zm=8,zw=8
> 
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Needs Code Review: Shared Randomness Generation for Tor

[Tim Wilson-Brown - teor]

> On 13 Jan 2016, at 01:46, George Kadianakis  wrote:
> 
> Hello there,
> 
> we are happy to tell you that we finished coding proposal 250 and our first
> attempt at implementation is ready for review.
> 
> You can find the final specification here:
> 
> https://gitweb.torproject.org/user/dgoulet/torspec.git/log/?h=prop250_final_v1
> and the corresponding code here:
> https://gitweb.torproject.org/user/dgoulet/tor.git/log/?h=prop250_final_v1
> 
> Trac ticket #16943 (https://trac.torproject.org/projects/tor/ticket/16943) 
> will
> be used for code review. Please use this mailing list to discuss any issues
> with the spec.
> 
> Some notes: We've separated this in 7 commits prefixed with prop250: except
> first one that adds a needed tor_htonll/ntohll function to tor utils. This 
> code
> is mostly contained in two *new* files (with their headers) that are
> shared-random.{c|h} and shared-random-state.{c|h}.
> 
> For what it's worth, we expect this code to run for a long time before the
> shared random values generated by the authorities are used for anything
> (e.g. HSDir scrambling).

I've seen you talk about using chutney for shared randomness generation.
Can you open a ticket with a branch for the chutney SR template, so people can 
use it for testing?
(And then we can merge it into chutney master about the same time this code 
goes into tor master.)

There's a make target, "test-network-all", that runs a series of chutney tests.
Each of these tests finish in around 35 seconds.

Can we get a SR chutney template to finish in around that time?
(With 10 second voting periods?)
What is the minimum number of voting periods that shared randomness requires?
(I understand the standard setting is 24, 12 for the commit, and 12 for the 
reveal.)

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] Proposal: Load Balancing with Overhead Parameters

[Tim Wilson-Brown - teor]

> On 13 Jan 2016, at 00:53, Mike Perry  wrote:
> 
> This proposal aims to allow us to load balance properly between Guard,
> Middle, and Exit nodes with the addition of padding traffic to the
> network.
> ...
> 1. Overview
> 
> For padding overhead due to Proposals 251 and 254, and changes to hidden
> service path selection in Proposal 247, it will be useful to be able to
> specify a pair of parameters that represents the additional traffic
> present on Guard and Middle nodes due to these changes.

I don't know if it's worth noting that proposals 252 and 260 (the Single Onion
Services variants) will reduce traffic to guard and middle nodes, as they
remove the nodes between the hidden service and client-controlled endpoint
(rendezvous point in Rendezvous Single Onion Services, extend point in
Single Onion Services).

I think these will just be part of the overhead parameters?

> ...
> 2. Simplified Load Balancing Equations
> 
> Recall that the point of the load balancing equations in section 3.8.3
> of dir-spec.txt is to ensure that an equal amount of client traffic is
> distributed between Guards, Middles, Exits, and Guard+Exits, where each
> flag type can occupy one or more positions in a path. This allocation is
> accomplished by solving a system of equations for weights for flag
> position selection to ensure equal allocation of client traffic for each
> position in a circuit.
> 
> If we ignore overhead for the moment and treat Guard+Exit nodes as Exit
> nodes, then this allows the simplified system of equations to become:
> 
>  Wgg*G == M + Wme*E + Wmg*G# Guard position == middle position
>  Wgg*G == Wee*E# Guard position == equals exit position
>  Wmg*G + Wgg*G == G# Guard allocation weights sum to 1
>  Wme*E + Wee*E == E# Exit allocation weights sum to 1
> 
> This system has four equations and four unknowns, and by transitivity we
> ensure that allocated capacity for guard, middle, and exit positions are
> all equal. Unlike the equations in 3.8.3 of dir-spec.txt, there are no
> special cases to the solutions of these equations because there is no
> shortage of constraints and no decision points for allocation based on
> scarcity. Thus, there is only one solution. Using SymPy's symbolic
> equation solver (see attached script) we obtain:
> 
>   E + G + M   E + G + M   2*E - G - M   2*G - E - M
>  Wee: -, Wgg: -, Wme: ---, Wmg: 
>  3*E 3*G  3*E   3*G
> 
> For the rest of the flags weights, we will do the following:
> 
>  Dual-flagged (Guard+Exit) nodes should be treated as Exits:
> Wgd = 0, Wmd = Wme, Wed = Wee
> 
>  Directory requests use middle weights:
> Wbd=Wmd, Wbg=Wmg, Wbe=Wme, Wbm=Wmm
> 
>  Handle bridges and strange exit policies:
> Wgm=Wgg, Wem=Wee, Weg=Wed

I think this analysis assumes that all paths in the Tor network are 3-hop paths.

What about the 4-hop paths created by circuit cannibalisation?
(We don't actually know what proportion of the Tor network has 3-hop vs 4-hop 
paths.)

Depending on whether an exit or internal circuit is cannibalised, they can look 
like:
G M E E
G M M E

And what about hidden service paths (paths that include two middle nodes?)
G M M

Or, if cannibalised from an exit or internal circuit:
G M E M
G M M M

Again, I think these will just be part of the overhead parameters?

> …

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] Questions about censorship detection paper

[David Fifield]

On Tue, Jan 12, 2016 at 11:49:19PM +, John wrote:
> Hi David,
> 
> Thank you, these pointers were very helpful. Do you know if there is
> some kind of resource that lists known censorship events? I'd like to
> see how good the approach from the paper does at identifying them.

For Tor-specific censorship, a list that is reasonably complete and up
to date is: http://www.eecs.berkeley.edu/~sa499/tor_timeline.pdf. It was
composed by mining the Tor issue tracker and blog for events.

For general censorship, I'm not aware of any systematic or complete list
of censorship events. There are quite a lot of research papers that
study one particular place for a period of time, and from them we know
of some incidents.

Here's a list of some measurement papers I'm aware of that might discuss
some events. You might also look at OpenNet and Freedom House reports.


Internet censorship in Iran: A first look
https://www.usenix.org/conference/foci13/workshop-program/presentation/aryan

The Anatomy of Web Censorship in Pakistan
https://www.usenix.org/conference/foci13/workshop-program/presentation/Nabi

Dimming the Internet: Detecting throttling as a mechanism of censorship in Iran
http://arxiv.org/abs/1306.4361

Global Network Interference Detection Over the RIPE Atlas Network
https://www.usenix.org/system/files/conference/foci14/foci14-anderson.pdf

Analysis of Country-wide Internet Outages Caused by Censorship
http://conferences.sigcomm.org/imc/2011/docs/p1.pdf

Characterizing Web Censorship Worldwide: Another Look at the OpenNet Initiative 
Data
http://censorbib.nymity.ch/pdf/Gill2015a.pdf
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Fwd: Orbot roadmap feedback

[Michael Rogers]

On 12/01/16 16:16, Nathan Freitas wrote:
> The broader idea is to determine which Tor torrc settings are relevant
> to the mobile environment, and that could use a more intuitive user
> interface than the empty text input we currently offer in our Settings
> panel. This may also mean implement a slider type interface mechanism
> similar to Tor Browser. In addition, users are interested in being able
> to control which network types (wifi vs 3g) Orbot runs on, in order to
> conserve spending on bandwidth.

Briar's TorPlugin has an option to disable Tor when using mobile data,
feel free to backport it to Orbot. Likewise for the plugin as a whole,
if it would be a suitable basis for LibOrbot. We've benefitted a lot
from your work and I'd love to send some contributions back upstream!

Cheers,
Michael


0x9FC527CC.asc
Description: application/pgp-keys


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

Re: [tor-dev] Fwd: Orbot roadmap feedback

[Nathan Freitas]

On Tue, Jan 12, 2016, at 10:48 AM, Georg Koppen wrote:
> Nathan Freitas:
> > - Overall improved configuration / settings UI to make tuning Orbot a
> > better, simpler experience... this is an expansion of the new exit
> > country selector in Orbot v15.1, but also includes managing things like
> > network usage and so on.
> 
> Could you explain that point a bit more, what you currently have and
> what you plan to do? Especially the exit country selector seems kind of
> scary to me but maybe I am just missing some bits. I looked at the
> changelog you sent to tor-talk (in the alpha 1 release mail) but did not
> find anything related.

The broader idea is to determine which Tor torrc settings are relevant
to the mobile environment, and that could use a more intuitive user
interface than the empty text input we currently offer in our Settings
panel. This may also mean implement a slider type interface mechanism
similar to Tor Browser. In addition, users are interested in being able
to control which network types (wifi vs 3g) Orbot runs on, in order to
conserve spending on bandwidth.

The Exit country selector option (basically a list of countries that
starts with "World" as the option) is definitely controversial, but it
is also something that comes up over and over again as a feature
request. It is expected especially of a VPN-style app, which Orbot now
is. It may be we only enable it when the VPN feature is enabled, and
disable it when Tor is used directly via SOCKS from the Orfox browser.
We may also need to just sufficiently warn and inform the user so they
can decide for themselves what to do.

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