Re: [tor-dev] GSOC'20

[Pili Guerra]

Hi Sanjiban,

(Moving tor-dev mailing list to bcc as we don’t need to continue this 
conversation on the mailing list.)

Thank you for your interest in contributing to Tor for GSoC 2020.

I would recommend you start off by reading the "Getting Started” sections for 
these projects and following the steps outlined there. Fee free to get back in 
touch if you get stuck.

You may also find it quicker to contact us on irc[1].

Good luck!

Pili

[1] https://trac.torproject.org/projects/tor/wiki/org/onboarding/IRC 

—
Project Manager: Tor Browser, UX and Community teams
pili at torproject dot org
gpg 3E7F A89E 2459 B6CC A62F 56B8 C6CB 772E F096 9C45

> On 21 Mar 2020, at 06:25, Sanjiban Sengupta  wrote:
> 
> Dear Sir,
> 
> This is Sanjiban Sengupta, sophomore in Computer Engineering from IIIT 
> Bhubaneswar, India, would like to contribute to Tor Project for GSoC'20, I 
> have practical and working knowledge of C, C++, Python and Java, for web, I 
> am familiar with HTML, CSS, JS, Bootstrap and frameworks such as ReactJS and 
> NodeJS, also i am acquainted with concepts of ML and AI, Linux Kernel and 
> know the technicalities to apply these to solve modern real life problems.
> 
> On going through the project proposals, I found the projectImplementing 
> Salmon as a bridge distribution mechanism, and Tor Weather interesting to 
> work upon and contribute and thus will be thankful for your kind guidance.
> 
> Thus I request the mentors to kindly guide me for the beginning processes.
> 
> Regards,
> Sanjiban Sengupta
> 
> 
> 
> On Sat, Mar 21, 2020 at 11:47 AM Sanjiban Sengupta  > wrote:
> Dear Sir,
> 
> This is Sanjiban Sengupta, sophomore in Computer Engineering from IIIT 
> Bhubaneswar, India, would like to contribute to Tor Project for GSoC'20, I 
> have practical and working knowledge of C, C++, Python and Java, for web, I 
> am familiar with HTML, CSS, JS, Bootstrap and frameworks such as ReactJS and 
> NodeJS, also i am acquainted with concepts of ML and AI, Linux Kernel and 
> know the technicalities to apply these to solve modern real life problems.
> 
> On going through the project proposals, I found the projectImplementing 
> Salmon as a bridge distribution mechanism, and Tor Weather interesting to 
> work upon and contribute and thus will be thankful for your kind guidance.
> 
> Thus I request the mentors to kindly guide me for the beginning processes.
> 
> Regards,
> Sanjiban Sengupta
> 
> 
> 
> On Sat, Mar 21, 2020 at 3:50 AM Sanjiban Sengupta  > wrote:
> Dear Sir,
> 
> This is Sanjiban Sengupta, sophomore in Computer Engineering from IIIT 
> Bhubaneswar, India, would like to contribute to Tor Project for GSoC'20, I 
> have practical and working knowledge of C, C++, Python and Java, for web, I 
> am familiar with HTML, CSS, JS, Bootstrap and frameworks such as ReactJS and 
> NodeJS, also i am acquainted with concepts of ML and AI, Linux Kernel and 
> know the technicalities to apply these to solve modern real life problems.
> 
> On going through the project proposals, I found the projectImplementing 
> Salmon as a bridge distribution mechanism, and Tor Weather interesting to 
> work upon and contribute and thus will be thankful for your kind guidance.
> 
> Thus I request the mentors to kindly guide me for the beginning processes.
> 
> Regards,
> Sanjiban Sengupta
> ___
> tor-dev mailing list
> tor-dev@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev



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

[tor-dev] Improving onion service availability during DoS using anonymous credentials

[George Kadianakis]

Hello list,

there has been lots of discussions about improving onion service availability
under DoS conditions. Many approaches have been proposed [OOO] but only a few
have been tried and even fewer show any real improvements to the availability
of the service.

An approach that we've been considering is the use of anonymous credentials as
a way to prioritize good clients from bad clients. The idea is that the service
gives tokens to clients it believes to be good, and prioritizes client with
tokens over clients without tokens whenever possible. This is a post to start a
discussion of how such approaches could work and whether they are worth
pursuing futher.

== Preliminaries ==

=== When should the access control take place? ===

Doing DoS defenses with anon credentials is all about enforcing access control
at the right point of the protocol so that the amplification factor of evil
clients gets cut as early as possible.

Very roughly the phases of the onion service protocol are: descriptor fetch
phase, intro phase, rendezvous phase. Let's see how those look like for the
purposes of access control:

- Doing the access control during the descriptor fetch stage is something worth
  considering because it's the first phase of the protocol and hence the
  earliest and best place to soak up any damage from evil clients. There is
  already a form of optional access control implemented here called "client
  authorization" and it's worth thinking of what's lacking to make it useful
  against DoS attackers. I'm gonna address this in section [CLIENTAUTH].

- Doing the access control during the introduction phase is another fruitful
  approach. Blocking bad clients during introduction means that they dont get to
  force the service to create a costly rendezvous circuit, and since services
  have a long-term circuit open towards the intro points it makes it easier for
  services to pass access control related data to the intro point. This is
  actually the approach we are gonna be talking most about in this post.

- Finally, doing the access control during the rendezvous phase is way too late
  since by that time the onion service has already spent lots of resources
  catering the evil client, so let's ignore that.

=== Entities of an anonymous credential system ===

Anonymous credential systems traditionally have three entities that concern us:

  - The Issuer:   the entity who issues the credentials/tokens
  - The Prover:   the entity who collects tokens and uses them to get 
access
  - The Verifier: the entity who verifies that tokens are legit and 
grants/restricts access

In the world of onion services, the Issuer is naturally the onion service, and
the Prover is the onion service client. The Verifier could either be
the onion service itself or its introduction points. We will see below how this
could work and the relevant tradeoffs.

 ++  ++   ++
 | Client |<-+-+-+-->|Intro point |<--+---+-->|Onion service   |
 |(Prover)|  |(Verifier?) |   |(Issuer)(Verifier?) |
 ++  ++   ++


=== How do tokens get around? ===

A main question here is "How do good clients end up with tokens?". For the
purposes of this post, we will assume that clients get these tokens in an out
of band fashion. For example, a journalist can give tokens to her sources over
Signal so they can use them with Securedrop. Or a forum operator can give
tokens to old-time members of the forum to be used during a DoS.

A natural chicken-and-egg problem occurs here since how is an onion service
supposed to give tokens to its users if it's unreachable because of a DoS? We
realize this is a big problem and we are not sure exactly how to solve it. This
problem naturally limits the use of anonymous credential solutions, and sorta
makes them a second-layer of defense since it assumes a first-layer of defense
that allows operators to pass tokens to the good people. A first-layer approach
here could perhaps look like PrivacyPass where users get tokens by solving
CAPTCHAs.

== Anonymous credentials ==

By surveying the anonymous credential literature we have found various types of
anonymous credential schemes that are relevant for us:

- Discrete-logarithm-based credentials based on blind signatures:

This is a class of anon credential schemes that allow us to separate the
verifier from the issuer. In particular this means that we can have the
service issue the tokens, but the introduction point being the verifier.

They are usually based on blind signatures like in the case of Microsoft's
U-Prove system [UUU].

- Discrete-logarithm-based credentials based on OPRF:

Another approach here is to use OPRF constructions based on the discrete
logarithm problem to create an anonymous credential scheme like in the case
of PrivacyPass [PPP]. The downside,

Re: [tor-dev] Improving onion service availability during DoS using anonymous credentials

[Jeff Burdges]

There is another component of the design space:

Do you want credentials to be movable from one introduction point to another?

If so, you can do this or not with both blind signatures and OPRFs by enabling 
or restricting their malleability properties, but probably not with anything 
symmetric.  If tokens are movable, then this encourages users to use multiple 
introduction points, but doing so sounds unlikely, but worse gives DoS 
attackers parallel access to introduction points.  I suppose no for this 
reason, but maybe it’s worth considering for the future..


> On 23 Mar 2020, at 14:23, George Kadianakis  wrote:
> - Discrete-logarithm-based credentials based on blind signatures:
> 
>This is a class of anon credential schemes that allow us to separate the
>verifier from the issuer. In particular this means that we can have the
>service issue the tokens, but the introduction point being the verifier.
> 
>They are usually based on blind signatures like in the case of Microsoft's
>U-Prove system [UUU].

We should mention that Fuchsbauer, et al. recently addressed the forgeability 
problem for blind Schnorr signatures in https://eprint.iacr.org/2019/877.pdf 
which should improve performance, but still costs more round trips than slower 
blind signature variants.  I think the attacks were never relevant for DoS 
protection anyways though.

You need 64 bytes for the Schnorr signature plus whatever you require to 
identify the signing key, so 80-96 bytes .

> - Discrete-logarithm-based credentials based on OPRF:
> 
>Another approach here is to use OPRF constructions based on the discrete
>logarithm problem to create an anonymous credential scheme like in the case
>of PrivacyPass [PPP]. The downside, IIUC, is that in PrivacyPass you can't
>have a different issuer and verifier so it's the onion service that needs
>to do the token verification restricting the damage soaking potential.

Issuer and verifier must share secret key material, so not exactly the same 
thing as being the same.  You must share some special public key material for 
the blind signatures.

I believe redemption could cost 64-96 bytes bytes, so a 32 byte curve point, a 
16-32 bytes that identifies the issuing key, and a 16-32 bytes seed that gets 
hashed to the curve.

Jeff





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

Re: [tor-dev] Tails vs the capacity of the Meek bridges

[David Fifield]

On Fri, Mar 20, 2020 at 11:51:41AM +0100, anonym wrote:
> tl;dr: if Tails makes it too easy to use Meek bridges, could it overload the 
> current set of Meek bridges?

The default meek bridge is already overloaded, unfortunately. Users
complain that even though it works, it is too slow. Reports of 20 KB/s
are typical. See for example this recent comment from China:
https://bugs.torproject.org/33219#comment:9
> ...with the pre integrated meek bridges I just had 20 kb/s, at most
> 30, sometimes even lower than 20. So it took me over one hour to
> download the browser.

Here's the brandwidth chart for the default meek bridge btw. I would
guess that the bridge is capable of going faster, but it may have a
BandwidthRate set to keep costs from getting out of control.
https://metrics.torproject.org/rs.html#details/8F4541EEE3F2306B7B9FEF1795EC302F6B84DAE8

It's possible to set up a special bridge just for Tails users. It
requires setting up a bridge with meek-server (this is the cheap part)
and configuring a CDN to point to it (this is the expensive part). But
then you can let it run as fast as your budget allows.
https://trac.torproject.org/projects/tor/wiki/doc/meek#MicrosoftAzure
https://trac.torproject.org/projects/tor/wiki/doc/meek#Howtorunameek-serverbridge
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev