Re: [tor-dev] UX improvement proposal: Onion auto-redirects using Alt-Svc HTTP header

[Georg Koppen]

George Kadianakis:
> As discussed in this mailing list and in IRC, I'm posting a subsequent
> version of this proposal. Basic improvements:
> - Uses a new custom HTTP header, instead of Alt-Svc or Location.
> - Does not do auto-redirect; it instead suggests the onion based on
>   antonella's mockup: 
> https://trac.torproject.org/projects/tor/attachment/ticket/21952/21952.png

I don't see that or any particular idea of informing the user in the
proposal itself, though. I think more about those browser side plans
should be specified in it (probably in section 2). Right now you are
quite specific about the redirection part and its pro and cons but
rather vague on the actual UX improvements (having the header is just
half of what you need).

> 
> 
> 
> UX improvement proposal: Onion redirects using Onion-Location HTTP header
> 
> 
> 1. Motivation:
> 
>Lots of high-profile websites have onion addresses these days (e.g. Tor ,

Tor,

>NYT, blockchain, ProPublica).  All those websites seem confused on what's
>the right way to inform their users about their onion addresses. Here are
>some confusion examples:
>  a) torproject.org does not even advertise their onion address to Tor 
> users (!!!)
>  b) blockchain.info throws an ugly ASCII page to Tor users mentioning 
> their onion
> address and completely wrecking the UX (loses URL params, etc.)
>  c) ProPublica has a "Browse via Tor" section which redirects to the 
> onion site.
> 
>Ideally there would be a consistent way for websites to inform their users
>about their onion counterpart. This would provide the following positives:
>  + Tor users would use onions more often. That's important for user
>education and user perception, and also to partially dispell the 
> darkweb myth.
>  + Website operators wouldn't have to come up with ad-hoc ways to 
> advertise
>their onion services, which sometimes results in complete breakage of
>the user experience (particularly with blockchain)
> 
>This proposal specifies a simple way forward here that's far from perfect,
>but can still provide benefits and also improve user-education around 
> onions
>so that in the future we could employ more advanced techniques.
> 
>Also see Tor ticket #21952 for more discussion on this:
>   https://trac.torproject.org/projects/tor/ticket/21952
> 
> 2. Proposal
> 
>We introduce a new HTTP header called "Onion-Location" with the exact same
>restrictions and semantics as the Location HTTP header. Websites can use 
> the
>Onion-Location HTTP header to specify their onion counterpart, in the same
>way that they would use the Location header.
> 
>The Tor Browser intercepts the Onion-Location header (if any) and informs
>the user of the existense of the onion site, giving them the option to 
> visit

s/existense/existence/

>it. Tor Browser only does so if the header is served over HTTPS.
> 
>Browsers that don't support Tor SHOULD ignore the Onion-Location header.
> 
> 3. Improvements

Did you plan to write anything here? I guess there are at least UX
improvements to the ad-hoc things you mentioned at the beginning of the
proposal.

> 4. Drawbacks
> 
> 4.1. No security/performance benefits
> 
>While we could come up with onion redirection proposals that provide
>security and performance benefits, this proposal does not actually provide
>any of those.
> 
>As a matter of fact, the security remains the same as connecting to normal
>websites (since we trust its HTTP headers), and the performance gets worse

s/its/their/

>since we first need to connect to the website, get its headers, and then
>also connect to the onion.
> 
>Still _all_ the website approaches mentioned in the "Motivation" section
>suffer from the above drawbacks, and sysadmins still come up with ad-hoc
>ways to inform users abou their onions. So this simple proposal will still

s/abou/about/

>help those websites and also pave the way forward for future auto-redirect
>techniques.
> 
> 4.2. Defining new HTTP headers is not the best idea
> 
>This proposal defines a new non-standard HTTP header. This is not great
>because it makes Tor into a "special" thing that needs to be supported with
>special headers. However, the fact that it's a new HTTP header that only
>works for Tor is a positive thing since it means that non-Tor browsers will
>just ignore it.
> 
>Furthermore, another drawback is that this HTTP header will increase the
>bandwidth needlessly if it's also served to non-Tor clients. Hence websites
>with lots of client traffic are encouraged to use tools that detect Tor
>users and only serve the header to them (e.g. tordnsel).
> 
> 5. The future
> 
>As previously discussed, this 

Re: [tor-dev] Proposal 288: Privacy-Preserving Statistics with Privcount in Tor (Shamir version)

[Aaron Johnson]

Hi Tim,

Prio allows a client to prove an arbitrary statement about a secret-shared 
input (expressed as as a circuit on that input) to a set of servers. This could 
provide some robustness against malicious inputs. However, it is not as much 
protection as we might really need because the circuit is only over one input, 
which prevents us from making relative comparisons across inputs. For example, 
Prio can provide a guarantee that an input value is at most some max value, but 
it can’t guarantee that a value isn’t over 1.5 times the max value of the 
*other* inputs. Identifying “outliers” relative to other inputs is important if 
you don’t know what the inputs are supposed to look like, which in Tor would be 
the case when “normal" inputs change due to underlying changes in network and 
user behavior.

Also, in Prio, servers use a generic secure multi-party computation (MPC) 
protocol to compute the circuits. If Tor is going to do that, why not just run 
a generic MPC protocol over all of the inputs? Doing so would allow Tor 
statistics aggregations to be robust to inputs that are likely “incorrect” 
given the values of the other inputs (see “robust statistics” for a wide 
variety of useful such computations, including for example median, trimmed 
mean, least trimmed squares, maximum likelihood estimation). Applying MPC over 
all inputs would only require implementing the “offline” phase of the 
computation (e.g. producing the “multiplication triples”, which are supplied by 
the client in Prio). There are reasonably efficient protocols for doing so, 
including SDPZ and TinyOT [1].

Best,
Aaron

[0] Ivan Damgard and Valerio Pastro and Nigel P. Smart and Sarah Zakarias, 
"Multiparty Computation from Somewhat Homomorphic Encryption", CRYPTO 2012, 
>.

[1] Enrique Larraia and Emmanuela Orsini and Nigel P. Smart, "Dishonest 
majority multi-party computation for binary circuits”, CRYPTO 2014, 
>.

> On Dec 12, 2017, at 9:04 PM, teor  wrote:
> 
>> 
>> On 2 Dec 2017, at 07:26, Nick Mathewson > > wrote:
>> 
>> Filename: 288-privcount-with-shamir.txt Title: Privacy-Preserving Statistics
>> with Privcount in Tor (Shamir version) Author: Nick Mathewson, Tim
>> Wilson-Brown, Aaron Johnson Created: 1-Dec-2017 Supercedes: 280 Status: Draft
>> 
>> 0. Acknowledgments
>> 
>> Tariq Elahi, George Danezis, and Ian Goldberg designed and implemented the
>> PrivEx blinding scheme. Rob Jansen and Aaron Johnson extended PrivEx's
>> differential privacy guarantees to multiple counters in PrivCount:
>> 
>> https://github.com/privcount/privcount/blob/master/README.markdown#research-background
>> 
>> Rob Jansen and Tim Wilson-Brown wrote the majority of the experimental
>> PrivCount code, based on the PrivEx secret-sharing variant. This
>> implementation includes contributions from the PrivEx authors, and others:
>> 
>> https://github.com/privcount/privcount/blob/master/CONTRIBUTORS.markdown
>> 
>> This research was supported in part by NSF grants CNS-539, CNS-1314637,
>> CNS-1526306, CNS-1619454, and CNS-1640548.
>> 
>> The use of a Shamir secret-sharing-based approach is due to a suggestion by
>> Aaron Johnson (iirc); Carolin Zöbelein did some helpful analysis here.
>> 
>> Aaron Johnson and Tim Wilson-Brown made improvements to the draft proposal.
>> 
>> 1. Introduction and scope
>> 
>> PrivCount is a privacy-preserving way to collect aggregate statistics about
>> the Tor network without exposing the statistics from any single Tor relay.
>> 
>> This document describes the behavior of the in-Tor portion of the PrivCount
>> system.  It DOES NOT describe the counter configurations, or any other
>> parts of the system. (These will be covered in separate proposals.)
>> 
>> 2. PrivCount overview
>> 
>> Here follows an oversimplified summary of PrivCount, with enough
>> information to explain the Tor side of things.  The actual operation of the
>> non-Tor components is trickier than described below.
>> 
>> In PrivCount, a Data Collector (DC, in this case a Tor relay) shares
>> numeric data with N different Tally Reporters (TRs). (A Tally Reporter
>> performs the summing and unblinding roles of the Tally Server and Share
>> Keeper from experimental PrivCount.)
>> 
>> All N Tally Reporters together can reconstruct the original data, but no
>> (N-1)-sized subset of the Tally Reporters can learn anything about the
>> data.
>> 
>> (In reality, the Tally Reporters don't reconstruct the original data at
>> all! Instead, they will reconstruct a _sum_ of the original data across all
>> participating relays.)
>> 
>> In brief, the system works as follow:
>> 
>> To share data, for each counter value V to be shared, the Data Collector
>> first adds Gaussian noise to V in order to produce V', uses (K,N) Shamir
>> secret-sharing to generate N shares of V' (K<=N, K being the reconstruction

Re: [tor-dev] IPv6 and v3 onion services

[David Goulet]

On 12 Dec (09:54:43), teor wrote:
> Hi David (and others interested in IPv6),
> 
> We want to add better IPv6 support to Tor relays, clients, and v3 onion 
> services.
> 
> But if we do IPv6 v3 onion services first, the hop before intro and rend 
> points
> will know that the circuit is a v3 onion service circuit, because its EXTEND2
> cells will have an IPv6 address.
> 
> So I suggest that we implement IPv6 support in this order:
> IPv6 single onion services (at any time, only uses direct IPv6 CREATE)
> IPv6 relay extends
> IPv6 relay reachability (provides cover traffic for IPv6 client extends)
> IPv6 client extends for exit circuits
> IPv6 client extends for multi-hop onion service circuits
> I've added this to an "Overview" section in: 
> https://trac.torproject.org/projects/tor/wiki/org/roadmaps/Tor/IPv6Features
> 
> I also like the idea of testing and deploying our IPv6 code on relays first.
> It's less risky than experimenting on clients or onion services.
> And our relay operators give us some excellent bug reports.
> 
> And we can re-use some of the common code from the relay implementation
> in the client and onion service implementations. (For example, we'll write
> code that handles link specifiers.)
> 
> Also, if we get IPv6 relay reachability checks working, that makes it easier
> to automatically configure IPv6 on relays. More IPv6 relays will make the
> anonymity set larger for IPv6 clients.
> 
> What do you think?

When I did some of IPv6 work on hidden service v3 (before we rolled it back
:P), we are missing IPv6 foundations in some places that I think would be good
to nail down before we do anything with HS.

The place I'm thinking of is the EXTEND in IPv6 and relay self-testing in
IPv6. This seems a more critical point to build into the network before we can
start building HS support on top (single onion is different but will have to
do with HS code in some ways).

Then, making sure a client can do IPv6 seems the natural next step. And then
we finish with HS.

So to summarize (in order of what I think we should do first):

1. Relay
2. Client
3. HS/Single Onion

My two cents on this.

Also, 033 freeze is arriving rather fast that is in theory mid-january so we
have to consider the fact that we might not get the whole thing in 033 but we
can certainly try :).

Cheers!
David

> 
> T
> 

-- 
PQgdff5S0a51LrwYmq/+PRgWSz+jjvkgZTCn3plzEkY=


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

Re: [tor-dev] IPv6 and v3 onion services

[teor]

> On 15 Dec 2017, at 03:29, David Goulet  wrote:
> 
> The place I'm thinking of is the EXTEND in IPv6 and relay self-testing in
> IPv6. This seems a more critical point to build into the network before we can
> start building HS support on top (single onion is different but will have to
> do with HS code in some ways).

I'm working on this right now.
It should be ready by mid-January, but it needs a proposal, so maybe it will
end up in 0.3.4 instead.

I would also like to make it easier to configure IPv6 relays. IPv6 support isn't
as useful as it could be, because only 15% of relays support IPv6.
Address autodetection would go a long way here.

> Then, making sure a client can do IPv6 seems the natural next step. And then
> we finish with HS.
> 
> So to summarize (in order of what I think we should do first):
> 
> 1. Relay
> 2. Client
> 3. HS/Single Onion
> 
> My two cents on this.

Seems good to me.
I want to try and focus on getting minimum working code.
Then we can add extra features later.

> Also, 033 freeze is arriving rather fast that is in theory mid-january so we
> have to consider the fact that we might not get the whole thing in 033 but we
> can certainly try :).

We can do parts in 0.3.3 and parts in 0.3.4.

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

Re: [tor-dev] IPv6 and v3 onion services

[David Goulet]

On 15 Dec (03:47:25), teor wrote:
> 
> > On 15 Dec 2017, at 03:29, David Goulet  wrote:
> > 
> > The place I'm thinking of is the EXTEND in IPv6 and relay self-testing in
> > IPv6. This seems a more critical point to build into the network before we 
> > can
> > start building HS support on top (single onion is different but will have to
> > do with HS code in some ways).
> 
> I'm working on this right now.
> It should be ready by mid-January, but it needs a proposal, so maybe it will
> end up in 0.3.4 instead.

Ok!

Can you tell me which ticket is that so I don't start poking at it? I think
without a nice layer of link specifier IPv6, we can't move forward on much
other things?

Let me know how I can be most useful here while you do that.

> 
> I would also like to make it easier to configure IPv6 relays. IPv6 support 
> isn't
> as useful as it could be, because only 15% of relays support IPv6.
> Address autodetection would go a long way here.

Are you suggesting something like "Address auto" or "ORPort auto:" kind
of thing that we enable by default for both v4 and v6 and then explicitly set
it if you want a specific address?

Auto detection of address becomes complicated with interfaces that have
multiple IPs... Which one do you choose?

But aren't you worried of Tor finding an IPv6 for a relay and starting using
it while the operator has no idea that it is happening? Dunno, maybe some
relays are bandwidth capped on v4 or/and v6 (would suck but)?

Anyway this can be a ticket (if not already done).

> 
> > Then, making sure a client can do IPv6 seems the natural next step. And then
> > we finish with HS.
> > 
> > So to summarize (in order of what I think we should do first):
> > 
> > 1. Relay
> > 2. Client
> > 3. HS/Single Onion
> > 
> > My two cents on this.
> 
> Seems good to me.
> I want to try and focus on getting minimum working code.
> Then we can add extra features later.

Agree++!

> 
> > Also, 033 freeze is arriving rather fast that is in theory mid-january so we
> > have to consider the fact that we might not get the whole thing in 033 but 
> > we
> > can certainly try :).
> 
> We can do parts in 0.3.3 and parts in 0.3.4.

Sure thing.

Cheers!
David

> 
> T

-- 
PQgdff5S0a51LrwYmq/+PRgWSz+jjvkgZTCn3plzEkY=


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

Re: [tor-dev] Proposal 249 updated

[teor]

Hi isis,

> On 14 Dec 2017, at 12:46, isis agora lovecruft  wrote:
> 
> 6.1. New Subprotocols and Subprotocol Versions
> 
>   This proposal introduces, following prop#264, the following new
>   subprotocol numbers and their uses.
> 
> 6.1.1. Relay Subprotocol
> 
> "Relay 3" -- The OP supports all of "Relay 2", plus support for CREATE2V
>   and CREATED2V cells and their above specification for link-layer
>   authentication specifiers.

We usually specify that the numbers will be allocated when the proposal
is merged. That avoids gaps in the numbering, and weird semantics like
"4 doesn't support 3".

In particular, an upcoming IPv6 proposal will need a new Relay protover,
and it might get merged in 0.3.3.

> 6.1.2. Link Subprotocol
> 
> "Link 5": The OP supports all of "Link 1-4", plus support for the new
>   EXTEND2 semantics.  Namely, it understands that an EXTEND2 cell whose
>   "hlen" field is greater than 505 will be followed by further "hdata"
>   in fragmented EXTEND2 cells which MUST follow.  It also understands
>   that the following combination of EXTEND2 payload specifiers
>   indicates that the cell is a continuation of the earlier payload
>   portions:
> 
>   nspec = 0;
>   htype = 0x;
>   hlen = 0;

Link version 5 is link padding, which was merged in 0.3.2:
https://gitweb.torproject.org/torspec.git/tree/tor-spec.txt#n571

> 6.1.3. Handshake Subprotocol
> 
>   Additionally, we introduce a new subprotocol, "Handshake" and the
>   following number assignments for previously occuring instances:
> 
> "Handshake 1" -- The OP supports the TAP handshake.
> 
> "Handshake 2" -- The OP supports the ntor handshake.
> 
>   We also reserve the following assignments for future use:
> 
> "Handshake 3" -- The OP supports the "hybrid+null" ntor-like handshake
>   from prop#269.
> 
> "Handshake 4" -- The OP supports a(n as yet unspecified) post-quantum
>   secure hybrid handshake, that is, the "hybrid+null" handshake from
>   "Handshake 3", except with "null" part replaced with another (as yet
>   unspecified) protocol to be composed with the ntor-like ECDH-based
>   handshake.
> 
>   Further handshakes MUST be specified with "Handshake" subprotocol
>   numbers, and MUST NOT be specified with "Relay" subprotocol numbers.  The
>   "Relay" subprotocol SHALL be used in the future to denote changes to
>   handshake protocol handling of CREATE* and EXTEND* cells, i.e. CREATE,
>   CREATED, CREATE_FAST, CREATED_FAST, CREATE2, CREATED2, CREATE2V,
>   CREATED2V, EXTEND, EXTENDED, EXTEND2, and EXTENDED2.
> 
>   Thus, "Handshake 1" is taken to be synonymous with "Relay 1", and
>   likewise "Handshake 2" is with "Relay 2".

Since this is a new protover field, it's ok to reserve numbers :-)

> 6.2. Subprotocol Recommendations
> 
>   After the subprotocol additions above, we change to recommending the
>   following in the consensus:
> 
>  recommended-client-protocols […] Link=5 Relay=3 Handshake=2
>  recommended-relay-protocols  […] Link=5 Relay=3 Handshake=2

I don't think we will want to jump straight to recommending the highest
protovers.

Is there a reason for this?
Does it lead to warnings on clients or relays?

>  required-client-protocols[…] Link=4-5 Relay=2-3 Handshake=1-2
>  required-relay-protocols […] Link=3-5 Relay=1-3 Handshake=1-2

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

Re: [tor-dev] IPv6 and v3 onion services

[teor]

On 15 Dec 2017, at 04:04, David Goulet  wrote:

>> On 15 Dec (03:47:25), teor wrote:
>> 
 On 15 Dec 2017, at 03:29, David Goulet  wrote:
>>> 
>>> The place I'm thinking of is the EXTEND in IPv6 and relay self-testing in
>>> IPv6. This seems a more critical point to build into the network before we 
>>> can
>>> start building HS support on top (single onion is different but will have to
>>> do with HS code in some ways).
>> 
>> I'm working on this right now.
>> It should be ready by mid-January, but it needs a proposal, so maybe it will
>> end up in 0.3.4 instead.
> 
> Ok!
> 
> Can you tell me which ticket is that so I don't start poking at it? I think
> without a nice layer of link specifier IPv6, we can't move forward on much
> other things?

Yes, it's important, and it would be great if you could do it.

Is that this ticket?

hs: Unify link specifier API/ABI
https://trac.torproject.org/projects/tor/ticket/22781

> Let me know how I can be most useful here while you do that.

Here is the wiki page I am using for planning:
https://trac.torproject.org/projects/tor/wiki/org/roadmaps/Tor/IPv6Features

Feel free to edit it :-)

Here's the high-level ticket, please pick any task I haven't started on:

https://trac.torproject.org/projects/tor/ticket/24403

>> I would also like to make it easier to configure IPv6 relays. IPv6 support 
>> isn't
>> as useful as it could be, because only 15% of relays support IPv6.
>> Address autodetection would go a long way here.
> 
> Are you suggesting something like "Address auto" or "ORPort auto:" kind
> of thing that we enable by default for both v4 and v6 and then explicitly set
> it if you want a specific address?

Eventually, but it doesn't need to be done in 0.3.3.

> Auto detection of address becomes complicated with interfaces that have
> multiple IPs... Which one do you choose?

Tor does this already with IPv4.

We check these sources for IPv4 (in about this order):
The configured Address
NETINFO cells from our outbound connections to other relays
The first IPv4 address in the order the OS provides them

I think we stopped using the X-Your-IP-Address-Is headers in
directory documents.

We check these sources for IPv6:
The first advertised IPv6 ORPort

Eventually, I want to make both use this order:
The configured Address
The first advertised ORPort
NETINFO cells from our outbound connections to other relays
The first address in the order the OS provides them

If we want to be clever, we can skip addresses that aren't reachable.
Or we can check all the addresses, and try to choose the shortest
address text to put in directory documents.
But these features can wait.

> But aren't you worried of Tor finding an IPv6 for a relay and starting using
> it while the operator has no idea that it is happening? Dunno, maybe some
> relays are bandwidth capped on v4 or/and v6 (would suck but)?

I've never heard of such a thing.
And we can't support every weird scenario by default.
There will be a way to turn the feature off.

I think we have to get used to treating IPv4 and IPv6 the same.
We guess IPv4, we should guess IPv6 as well.

If we need to have a release where the feature is available but off by default,
that's ok. But I think it's not a big deal. Let's just tell people at the top 
of the
release notes.

It will make a lot of relay operators happy.

> Anyway this can be a ticket (if not already done)

Reachability checks are:

Missing IPv6 ORPort reachability check
https://trac.torproject.org/projects/tor/ticket/6939

I'm sure we have a ticket for relay IPv6 autodetection, but I can't find it
right now.

T

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

Re: [tor-dev] IPv6 and v3 onion services

[David Goulet]

On 15 Dec (04:31:45), teor wrote:
> On 15 Dec 2017, at 04:04, David Goulet  wrote:
> 
> >> On 15 Dec (03:47:25), teor wrote:
> >> 
>  On 15 Dec 2017, at 03:29, David Goulet  wrote:
> >>> 
> >>> The place I'm thinking of is the EXTEND in IPv6 and relay self-testing in
> >>> IPv6. This seems a more critical point to build into the network before 
> >>> we can
> >>> start building HS support on top (single onion is different but will have 
> >>> to
> >>> do with HS code in some ways).
> >> 
> >> I'm working on this right now.
> >> It should be ready by mid-January, but it needs a proposal, so maybe it 
> >> will
> >> end up in 0.3.4 instead.
> > 
> > Ok!
> > 
> > Can you tell me which ticket is that so I don't start poking at it? I think
> > without a nice layer of link specifier IPv6, we can't move forward on much
> > other things?
> 
> Yes, it's important, and it would be great if you could do it.
> 
> Is that this ticket?
> 
> hs: Unify link specifier API/ABI
> https://trac.torproject.org/projects/tor/ticket/22781

Sure! I've already done much work on it but stopped because I wasn't sure
which direction we want to go. I've tried to summarize it in:

https://trac.torproject.org/projects/tor/ticket/22781#comment:6

Any feedback would be very appreciated so I can finalize this for review.

Cheers!
David

-- 
PQgdff5S0a51LrwYmq/+PRgWSz+jjvkgZTCn3plzEkY=


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

Re: [tor-dev] Proposal 288: Privacy-Preserving Statistics with Privcount in Tor (Shamir version)

[teor]

Hi Aaron,

> On 15 Dec 2017, at 01:54, Aaron Johnson  wrote:
> 
> in Prio, servers use a generic secure multi-party computation (MPC) protocol 
> to compute the circuits. If Tor is going to do that, why not just run a 
> generic MPC protocol over all of the inputs? Doing so would allow Tor 
> statistics aggregations to be robust to inputs that are likely “incorrect” 
> given the values of the other inputs (see “robust statistics” for a wide 
> variety of useful such computations, including for example median, trimmed 
> mean, least trimmed squares, maximum likelihood estimation). Applying MPC 
> over all inputs would only require implementing the “offline” phase of the 
> computation (e.g. producing the “multiplication triples”, which are supplied 
> by the client in Prio). There are reasonably efficient protocols for doing 
> so, including SDPZ and TinyOT [1].

If I understand you correctly, you are saying that we can add
a secure multiparty computation to the Tally Reporters without
changes on the Data Collectors?

Great!

Then let's proceed with the Data Collector implementation as
specified in this proposal. We can decide how we detect
outliers when we specify the Tally Reporter implementation.

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

Re: [tor-dev] Proposal 288: Privacy-Preserving Statistics with Privcount in Tor (Shamir version)

[Aaron Johnson]

>> in Prio, servers use a generic secure multi-party computation (MPC) protocol 
>> to compute the circuits. If Tor is going to do that, why not just run a 
>> generic MPC protocol over all of the inputs? Doing so would allow Tor 
>> statistics aggregations to be robust to inputs that are likely “incorrect” 
>> given the values of the other inputs (see “robust statistics” for a wide 
>> variety of useful such computations, including for example median, trimmed 
>> mean, least trimmed squares, maximum likelihood estimation). Applying MPC 
>> over all inputs would only require implementing the “offline” phase of the 
>> computation (e.g. producing the “multiplication triples”, which are supplied 
>> by the client in Prio). There are reasonably efficient protocols for doing 
>> so, including SDPZ and TinyOT [1].
> 
> If I understand you correctly, you are saying that we can add
> a secure multiparty computation to the Tally Reporters without
> changes on the Data Collectors?

Yes, that is correct. The MPC servers would get the (secret-shared) inputs, and 
then instead of just adding them and publishing the result, they would perform 
an MPC computation on them.

Now, we could in theory improve Data Collectors so that they can obliviously 
maintain statistics that aren’t just counts. For example, this would enable us 
to store a maximum of observed values (e.g. most streams per circuit seen over 
all circuits through that exit). How that could be done with adequate 
efficiency isn’t clear to me, though (it seems like a research question).

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