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

[grarpamp]

On Tue, Jan 12, 2016 at 9:58 AM, coderman  wrote:
> 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?

Bandwidth peering contracts preferential to push or eyeball traffic.
___
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

[David Goulet]

On 13 Jan (11:34:05), Tim Wilson-Brown - teor wrote:
> 
> > 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.)

We've done extensive testing already with chutney. I don't think we need
a specific SR template since this is part of the voting system which
ultimately put the SR values in the consensus.

I mostly used the "hs" template for this and sometimes used a variation
of it with 9 dirauths instead of 3.

> 
> 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.)

For now, that won't be possible :S, the number of rounds per phase (12
commits and 12 reveals) are hardcoded so no torrc options to change
them. We could make it that in TestingNetwork, this is divided by 4
having 3 and 3 but then we are at 60 seconds so :S... Do you think even
just that would be useful?

On the other hand, a very very useful test would be to have a way to
kill/spawn/kill/spawn dirauth to simulate reboots or a way to make them
miss voting periods. That doesn't sound to me that crazy difficult to
achieve with chutney and in that case we could have an epic SR template
that imposes conditions on dirauth lifetime.

Thanks!
David

> 
> Tim
> 
> Tim Wilson-Brown (teor)
> 
> teor2345 at gmail dot com
> PGP 968F094B
> 
> teor at blah dot im
> OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F
> 



> ___
> 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

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

[coderman]

On 1/13/16, grarpamp  wrote:
> On Tue, Jan 12, 2016 at 9:58 AM, coderman  wrote:
>> ... only question is who would have a
>> compelling use for separating outbound OR connections and outbound
>> Exit traffic, as per #17975?
>
> Bandwidth peering contracts preferential to push or eyeball traffic.


have you ever set this up for a Tor relay? really?

i've done plenty of networking on multi-homed systems and run relays
many years, yet never had to go beyond existing behavior with the
outbound bind address. Exit binding as distinct option might be
useful, yet no one has defined a reasonable scenario for such utility.


best regards,
___
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 20:02, David Goulet  wrote:
> 
> On 13 Jan (11:34:05), Tim Wilson-Brown - teor wrote:
>> 
>>> On 13 Jan 2016, at 01:46, George Kadianakis  wrote:
>>> 
>>> ...
>>> 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.)
> 
> We've done extensive testing already with chutney. I don't think we need
> a specific SR template since this is part of the voting system which
> ultimately put the SR values in the consensus.
> 
> I mostly used the "hs" template for this and sometimes used a variation
> of it with 9 dirauths instead of 3.
> 
>> 
>> 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.)
> 
> For now, that won't be possible :S, the number of rounds per phase (12
> commits and 12 reveals) are hardcoded so no torrc options to change
> them. We could make it that in TestingNetwork, this is divided by 4
> having 3 and 3 but then we are at 60 seconds so :S... Do you think even
> just that would be useful?

If the minimum number of rounds per phase is 3, then let's set it at 3 in test 
networks.
(But leave it as a configurable, test-network-only parameter, like the many 
other test network parameters.)
60 seconds is better than 240 seconds, and it means the tests are more likely 
to get run.

> On the other hand, a very very useful test would be to have a way to
> kill/spawn/kill/spawn dirauth to simulate reboots or a way to make them
> miss voting periods. That doesn't sound to me that crazy difficult to
> achieve with chutney and in that case we could have an epic SR template
> that imposes conditions on dirauth lifetime.

I think this is one of those future features that would require a rewrite of 
chutney, or at least substantially more code.
I agree it would be useful.

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] Comparing Stem, metrics-lib, and zoossh

[Damian Johnson]

> This was Stem commit c01a9cda4e7699c7f4bd642c8e81ed45aab7a29b and
> Python version 2.7.10.

Great, thanks! Also what was the metrics-lib and zoossh commits?

> Or should we add these performance tests for metrics-lib, Stem, and
> Zoossh to their own repository that also comes with scripts to fetch
> data from CollecTor?  (Not sure if this is a smart thing to do, but I
> figured I should ask before adding things to the metrics-lib repository.)

Sinister plan #572 is that I'll add these results and scripts to the
page we have with the library comparison. Probably tomorrow. If you'd
care to clean up the metrics-lib examples that would be great.
Otherwise I'll include what we have and you can send me patches later
with what you'd like.

Cheers! -Damian
___
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 17:19, Damian Johnson wrote:
> Thanks! Yup, those results look reasonable. I was expecting a
> smaller delta with server/extrainfo descriptors and larger one
> with microdescriptors due to the lazy loading but oh well. What
> stem commit and python version was this with?

This was Stem commit c01a9cda4e7699c7f4bd642c8e81ed45aab7a29b and
Python version 2.7.10.

> Any thoughts on when you'll have time to clean up the metrics-lib 
> examples? Happy to add the results to our site when they're ready.

Or should we add these performance tests for metrics-lib, Stem, and
Zoossh to their own repository that also comes with scripts to fetch
data from CollecTor?  (Not sure if this is a smart thing to do, but I
figured I should ask before adding things to the metrics-lib repository.)

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

iQEcBAEBAgAGBQJWlpnzAAoJEJD5dJfVqbCrn60IAMQy2RJR4eN66en8wDnOjPNZ
c3xjQfcZg2vTYtUO9f5Uj4Hx4PYbodGxnS6m4r6+xtAnT1PpPzMc7O8bbEJNhAWD
1a9gVUvy4OYPYXsCGY9KlyIbmwCgSyXRj+Kb4C0Levd7xQ7C6Yvku6nWw3OZlJz8
K5t4TKPrU5ScovlxOfKTijytvNKfX16vO0vjC1w+WN5oex4UbGLRbtHLQlf3ZOmz
hlvzWrSd7SdTNMEEpG01iZ8HxqEQLCapbWYg32KzheXW8W1NBTBm0abh1F4jGZbX
UYKKBg5+E2/sxPfvyCACkRnP1ulfENSyt8kvD2qFquxp/cwuHuZC0XtCkKARSII=
=YX00
-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%)

[grarpamp]

On Wed, Jan 13, 2016 at 4:27 AM, coderman  wrote:
>>> ... only question is who would have a
>>> compelling use for separating outbound OR connections and outbound
>>> Exit traffic, as per #17975?
>>
>> Bandwidth peering contracts preferential to push or eyeball traffic.

> outbound bind address. Exit binding as distinct option might be
> useful, yet no one has defined a reasonable scenario for such utility.

another reason could be separating the exitIP as
sacrificial on abuse complaint and/or set in a freeforall dmz,
where orIP may more neutral and/or long term.

don't know if anyone has deployed on any of these potential reasons.
___
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

[Philipp Winter]

On Wed, Jan 13, 2016 at 05:47:03PM +0100, Karsten Loesing wrote:
> Do the Zoossh results there look plausible?

I'm surprised that descriptor parsing is so slow, but I think the
results are plausible, yes.  I should look into it.

Thanks,
Philipp
___
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

[s7r]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hello,

I am not a big fan of prop 246. I don't have a mindblowing counter
argument that it's bad in some way, but I don't like the tradeoffs vs
benefits ratio so much. It is a small performance improvement indeed,
so clients will not cache descriptors and have to create 1 circuit
instead of 2 before the rendezvous circuit but I don't think this is a
big problem anyway. Hidden service servers use circuits to publish
their descriptors to the corresponding HSDirs and close them without
having to do it again too soon if nothing changes and also keep the
circuits to the introduction points alive for a random number of
INTRODUCE2 cells or amount of time, again not having to create new
ones very soon.

Proposal 250 is a major step forward in making HSDirs less dangerous
and eliminates some attacks. I am super happy we have it ready that fast.

I am also slightly uncomfortable that under prop 246 I must keep open
a long lived circuit to relays not of my choice (merged HSDir + IP
decided network wide based on shared randomness value). And I have to
do it regardless how many INTRODUCE2 cells I get through them and for
a mostly fixed amount of time.

This is also a bullet in the head for hidden service popularity leaks
if the HSDir+IP can identify the service (knows the unblinded key). A
merged HSDir + IP knows the popularity of a hidden service with a very
low error margin in this case (say $LEARNED_POPULARITY * 6 =
$POPULARITY). In current design introduction points see a random
number of INTRODUCE cells from 16k to 32k. Obviously a spying
introduction point can assume that a hidden service is popular if it
received 18000 introductions in 2 hours for example... but it's a
difference between assuming something with a somewhat error margin and
having some very precise figures.

Load balancing is also a problem. Without prop 246 load balancing is
shared, the HSDirs serve the descriptors and other relays act as
introduction points (and are rotated), but will the same set of relays
be able to handle both of these (and not just for one hidden service,
but for multiple at the same time)? The amount of traffic experienced
by introduction points is significantly bigger than the amount of
traffic experienced by HSDirs given one hidden service (noticed this
back when we tested onionbalance) so rotating introduction points as
we currently do is a sane thing to do from this point of view. True
that we have some amazing weighted hash ring suggestions, but
concentrating too much information and traffic into highest bandwidth
relays in the network doesn't sound attractive because as we an
attacker doesn't need to physically seize a relay for some attacks to
work - he can just watch upstream for some traffic correlations
attacks to work.

Being able to tweak the number of introduction points at hidden
service server side is helpful for increasing capacity and load
balancing. Disabling this option will cause problems in the future,
because a network wide param setting the introduction points for all
hidden services regardless their popularity or need doesn't sound
attractive.

After prop 250, a malicious HSDir can not do so much, but a merged
HSDir + IP can for example kill the circuit and force the hidden
service to rebuild it. Under the current design, we retry for some
times and give up if an introduction point is unreliable, but with 246
we have to retry much more. If the same attacker also holds a
reasonable % of middle bandwidth fraction in the Tor network, it will
at least perform a successful guard discovery over the hidden service
which is terrible. This may be fixed by not retrying a HSDir+IP too
many times as described in section 4.3 of the proposal, but it will
automatically lead to a capacity decrease (we have 5 HSDir + IP left
out of 6).

All these might not mean too much, but I am inclined to say prop 246
doesn't offer us too many benefits. I do like it very much that prop
246 will make clients to stop caching descriptors and hidden services
be dependent on less relays overall - I am only double thinking if
it's worth it or not.

Looking forward to read comments from others as well. Thanks!

On 1/13/2016 6:50 PM, George Kadianakis wrote:
> Hello there,
> 
> we recently finished implementing proposal 250 which is one of the
> first steps for the upcoming hidden service redesign [1]. The next
> steps are implementing proposal 224 and the other performance and
> security proposals [2].
> 
> On this note, one of the open design issues that we need to tackle
> next is whether we should do proposal 246 or not. Proposal 246
> merges HSDirs and Intro Points into a single entity to simplify the
> protocol and improve its performance. The idea is that HSes will
> pick their intro points using the hash ring algorithm currently
> used for picking HSDirs. Clients will do the same and connect
> directly to the intro points instead of going through the HSDir
> step.
> 
> I suggest 

[tor-dev] txtorcon: ipaddress instead of ipaddr?

[meejah]

Regarding https://github.com/meejah/txtorcon/pull/155 does anyone have a
good reason not to move txtorcon to using "ipaddress" -- this is a built-in
library on Python3, with backports to Python2.

Thanks,
meejah
___
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

[Tim Wilson-Brown - teor]

Hi,

I also have concerns about proposal 246, I don't think its benefits are 
compelling
compared with the number of drawbacks.

If we do want to skip the introduction point, proposal 252 (single onion 
services)
provides a way for onion services to do this on an opt-in basis. (However, it 
doesn't
allow onion services to skip the introduction point step and stay 
location-hidden.)

There's also nothing preventing us from making this change in future, by 
modifying
how hidden services select their introduction points. We could then teach 
clients
to use the HSDir as an introduction point if it's in the list.

> On 14 Jan 2016, at 03:50, George Kadianakis  wrote:
> 
> Hello there,
> ...
> Here are some issues that make this proposal not an obvious pick:
> 
> 1) Security issues
> ...
>   - It was also pointed out that the HSDir algorithm does not take into
> account the bandwidth of the nodes, making it easier to launch Sybil
> attacks.  However, the rest of the the mailing list thread suggests
> various ways to do bandwidth weighted hash ring selections [4], so this
> might not be an important factor.

As far as I recall, there was no guarantee that a large hidden service would
not pick 6 low-bandwidth HSDirs/IPs for a day, with serious impact on the
reachability of that hidden service for that period.

> 3) Load balancing issue
> ...
>   - Another concern here is that hidden services would not be able to change
> the number of their introduction points. This is not a big problem
> currently, but it could become in the future if the network gets more
> overloaded. As a partial solution to this, #17690 suggests making the
> number of HSDirs a network-wide consensus parameter that could also be
> used by proposal 246.

It could also become a big problem for large hidden services which benefit from
10 (or more) introduction points.

> 2) Reachability issue
> 
>   A final issue here is that if the relay churn of the network increases, the
>   introduction point hash ring might be changing rapidly and clients might get
>   pointed to the wrong introduction points.
> 
>   However, this does not seem like a greater problem than what hidden services
>   are facing with HSDir reachability currently. Is this right, or does prop246
>   makes it worse?

Proposal 246 makes it worse, because now both HSDirs and introductions depend
on a potentially churning hash ring. If churn makes an introduction point
unreachable, this increases the load on the other introduction points.

Clients also cache descriptors from HSDirs, but they need an introduction point
to be up whenever they contact the hidden service.

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] How many exits exit from an IP address different than their OR address? (10.7%)

[Virgil Griffith]

In our quantifications of relay diversity, knowing the IP addresses that
traffic exits from is important. Ways to have this information correctly
reported would be very helpful.

-V
On Thu, 14 Jan 2016 at 03:01 grarpamp  wrote:

> On Wed, Jan 13, 2016 at 4:27 AM, coderman  wrote:
> >>> ... only question is who would have a
> >>> compelling use for separating outbound OR connections and outbound
> >>> Exit traffic, as per #17975?
> >>
> >> Bandwidth peering contracts preferential to push or eyeball traffic.
>
> > outbound bind address. Exit binding as distinct option might be
> > useful, yet no one has defined a reasonable scenario for such utility.
>
> another reason could be separating the exitIP as
> sacrificial on abuse complaint and/or set in a freeforall dmz,
> where orIP may more neutral and/or long term.
>
> don't know if anyone has deployed on any of these potential reasons.
> ___
> 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] Fwd: Orbot roadmap feedback

[Nathan Freitas]

On Tue, Jan 12, 2016, at 11:52 AM, Michael Rogers wrote:
> 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!

Is TorPlugin already a distinct library / module?

+n
___
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

[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 attached a small tool that should do the same thing Damian's script
does for consensuses and server descriptors.  Note, however, that it
cannot processed tar archives.  It expects as input directories that
contain consensuses and server descriptors.

You can compile it with "go build benchmark.go".

Cheers,
Philipp
package main

import (
"fmt"
"log"
"os"
"path/filepath"
"time"

"git.torproject.org/user/phw/zoossh.git"
)

var processedCons int64 = 0
var processedDescs int64 = 0
var totalExits int64 = 0
var totalRelays int64 = 0
var totalBw uint64 = 0

func Min(a uint64, b uint64, c uint64) uint64 {

min := a

if b < min {
min = b
}

if c < min {
min = c
}

return min
}

func ProcessDescriptors(path string, info os.FileInfo, err error) error {

if _, err := os.Stat(path); err != nil {
return err
}

if info.IsDir() {
return nil
}

consensus, err := zoossh.ParseDescriptorFile(path)
if err != nil {
return err
}

if (processedDescs % 100) == 0 {
fmt.Printf(".")
}

for _, getDesc := range consensus.RouterDescriptors {
desc := getDesc()
totalBw += Min(desc.BandwidthAvg, desc.BandwidthBurst, 
desc.BandwidthObs)
processedDescs++
}

return nil
}

func ProcessConsensus(path string, info os.FileInfo, err error) error {

if _, err := os.Stat(path); err != nil {
return err
}

if info.IsDir() {
return nil
}

consensus, err := zoossh.ParseConsensusFile(path)
if err != nil {
return err
}
fmt.Printf(".")

for _, getStatus := range consensus.RouterStatuses {
status := getStatus()
totalRelays++
if status.Flags.Exit == true {
totalExits++
}
}
processedCons++

return nil
}

func main() {

if len(os.Args) != 3 {
log.Fatalf("Usage: %s CONSENSUS_ARCHIVE DESCRIPTOR_ARCHIVE", 
os.Args[0])
}

before := time.Now()
filepath.Walk(os.Args[1], ProcessConsensus)
fmt.Println()
after := time.Now()

duration := after.Sub(before)
fmt.Println("Total time for consensuses:", duration)
fmt.Printf("Time per consensus: %dms\n",
duration.Nanoseconds()/processedCons/int64(100))
fmt.Printf("Processed %d consensuses with %d router status entries.\n",
processedCons, totalRelays)
fmt.Printf("Total exits: %d\n", totalExits)

before = time.Now()
filepath.Walk(os.Args[2], ProcessDescriptors)
fmt.Println()
after = time.Now()

duration = after.Sub(before)
fmt.Println("Total time for descriptors:", duration)
fmt.Printf("Time per descriptor: %dns\n",
duration.Nanoseconds()/processedDescs)
fmt.Printf("Processed %d descriptors.\n", processedDescs)
fmt.Printf("Average advertised bandwidth: %d\n", 
totalBw/uint64(processedDescs))
}
___
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 13/01/16 16:28, Philipp Winter wrote:
> 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 attached a small tool that should do the same thing Damian's
> script does for consensuses and server descriptors.  Note, however,
> that it cannot processed tar archives.  It expects as input
> directories that contain consensuses and server descriptors.
> 
> You can compile it with "go build benchmark.go".

Cool, thanks!  I added the Zoossh results below.

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

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

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

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

Do the Zoossh results there look plausible?

All the best,
Karsten

-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org

iQEcBAEBAgAGBQJWln+HAAoJEJD5dJfVqbCruJgIAJbd0mYKE7qYEZgdh1zhN4Bs
bdiLLJqrwY5PEY2OSJ2mZ4nPelgc4vnWU93dihZMfjBSKD9OokbS3+a0x7ErVtt3
s8pPuKKs2blNDliSNsHuK/dQwEjLGZgxtOxtrYDpTL+oMAU/cZ2S3t3joSlX9Dfh
EnXCrVc3pfMyDbANaO2bf8Vz0qP2ps0Gd+JE5XRjwkJtebAXV4UJ5LRH+wedChBa
zpUPLMrBET+sWMzs5vxWRhAbmJcrV/tkZmgBmiuvcuTeu8fc4xejsxKKQx4jhYKR
hVx5sH679MXoS4ODDCC0RUIgB+PFg7/cEBGPSDPGxAvuonEQXwCyatR0Opj9gMc=
=754/
-END PGP SIGNATURE-
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

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

[George Kadianakis]

Hello there,

we recently finished implementing proposal 250 which is one of the first steps
for the upcoming hidden service redesign [1]. The next steps are implementing
proposal 224 and the other performance and security proposals [2].

On this note, one of the open design issues that we need to tackle next is
whether we should do proposal 246 or not. Proposal 246 merges HSDirs and Intro
Points into a single entity to simplify the protocol and improve its
performance. The idea is that HSes will pick their intro points using the hash
ring algorithm currently used for picking HSDirs. Clients will do the same and
connect directly to the intro points instead of going through the HSDir step.

I suggest you read the proposal and the discussion thread to become better
informed about this idea:
 https://lists.torproject.org/pipermail/tor-dev/2015-July/009079.html

Proposal 246 changes the hidden service protocol substantially, which is why we
need to decide whether to do it soon. The next steps in our implementation plan
heavily depend on whether we will do proposal 246 or not.

Here are some issues that make this proposal not an obvious pick:

1) Security issues

   - Professor Hopper pointed out [3] that this proposal will double the number
 of introduction points of a hidden service (from the current 3 to 6).
 Introduction points have slightly more attack vectors than HSDirs, so we
 should not increase their number without analyzing further.

 That said we could potentially increase the number of intro points by
 doing proposal 246, and at the same time we could also increase their
 lifetime period to multiple days (instead of the current 18-24 hours
 lifetime), to keep the exposure of hidden services to an acceptable value.

   - It was also pointed out that the HSDir algorithm does not take into
 account the bandwidth of the nodes, making it easier to launch Sybil
 attacks.  However, the rest of the the mailing list thread suggests
 various ways to do bandwidth weighted hash ring selections [4], so this
 might not be an important factor.

3) Load balancing issue

   - With proposal 246, the Tor network decides which relays will be used as
 the introduction points of a hidden service. A hidden service cannot pick
 its own introduction points, similarly to how currently a hidden service
 cannot pick its own HSDirs.

 This is a problem because it blocks load balancing solutions like
 onionbalance from working. Variants of the onionbalance logic can still
 work as suggested in the proposal [5], at the cost of increased
 engineering and sysadmin complexity.

   - Another concern here is that hidden services would not be able to change
 the number of their introduction points. This is not a big problem
 currently, but it could become in the future if the network gets more
 overloaded. As a partial solution to this, #17690 suggests making the
 number of HSDirs a network-wide consensus parameter that could also be
 used by proposal 246.

2) Reachability issue

   A final issue here is that if the relay churn of the network increases, the
   introduction point hash ring might be changing rapidly and clients might get
   pointed to the wrong introduction points.

   However, this does not seem like a greater problem than what hidden services
   are facing with HSDir reachability currently. Is this right, or does prop246
   makes it worse?

Personally, I'm not that concerned about the security issues I outlined
above. I think the security difference will not be that great, and maybe we can
equalize it by using some of the listed solutions. However, more thinking is
required.

I'm currently more concerned about the load balancing and reachability issues
that I outlined above and maybe others that I forget. I would like to have more
assurance that relay churn will not cause reachability issues to the proposal
246 system before we commit to it.

Feedback is very welcome. Also please post any issues that I forgot to mention.

We should try to figure out what to do here as soon as possible.

If we fail to come to a conclusion here, our engineering plan is to ignore
proposal 246 and continue with proposal 224 like it never happened. Of course
this will suck if we later decide that proposal 246 was super important and
should have happened.

Cheers!

[1]: https://lists.torproject.org/pipermail/tor-dev/2016-January/010182.html
[2]: https://lists.torproject.org/pipermail/tor-dev/2015-October/009762.html
[3]: https://lists.torproject.org/pipermail/tor-dev/2015-July/009093.html
[4]: https://lists.torproject.org/pipermail/tor-dev/2015-July/009163.html
[5]: 
https://gitweb.torproject.org/torspec.git/tree/proposals/246-merge-hsdir-and-intro.txt#n227
___
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 13/01/16 16:04, Nathan Freitas wrote:
> On Tue, Jan 12, 2016, at 11:52 AM, Michael Rogers wrote:
>> 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!
> 
> Is TorPlugin already a distinct library / module?

It's not, but it should be easy to separate, especially if you only need
to run on Android. An earlier version of TorPlugin was forked into an
Android/J2SE library by the Thali project, but I'd recommend starting
from the current version of the plugin.

https://github.com/thaliproject/Tor_Onion_Proxy_Library

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