Re: [tor-dev] Scalability or Onionbalance for v3 ephemeral/ADD_ONION services

Holmes Wilson writes: > Hi George, > > Sorry for the slow reply here! Just getting back to this. > >>> For our application (a messaging app) it would be super useful to get the >>> full list of known online (or recently seen online) onion addresses in >>> possession of some frontend key. This

Re: [tor-dev] A series of questions about Tor (m1 support, forward secrecy, v3 auth)

Holmes Wilson writes: > Hi everyone, > Hello Holmes, here are some attempts to answer your questions. > 2. FORWARD SECRECY > > Is there a good source for documentation on how forward secrecy works in Tor, > and on what security guarantees it provides? Googling finds things like this >

Re: [tor-dev] Scalability or Onionbalance for v3 ephemeral/ADD_ONION services

be interested in working with others on a spec for this! > > On Mon, Jun 14, 2021 at 6:25 AM George Kadianakis > wrote: > >> Chad Retz writes: >> >> > A quick glance at the code shows that ADD_ONION (i.e. "ephemeral" >> > onion services) d

Re: [tor-dev] Scalability or Onionbalance for v3 ephemeral/ADD_ONION services

Chad Retz writes: > A quick glance at the code shows that ADD_ONION (i.e. "ephemeral" > onion services) doesn't support setting an Onionbalance > frontend/master onion address (specifically > https://gitlab.torproject.org/tpo/core/tor/-/issues/32709 doesn't seem > to have a control-side

[tor-dev] [RFC] Proposal 332: Vanguards lite

Hello list, I present you with a simplified version of prop292 which protects against guard discovery attacks. The proposal can also be found in: https://gitlab.torproject.org/asn/torspec/-/commits/vg-lite --- ``` Filename: 332-vanguards-lite.md Title: Vanguards lite Author: George

Re: [tor-dev] Uptime stats for "Tor user can access an otherwise-functional hidden service"?

Holmes Wilson writes: > And I just saw today's blog post about the new status page. Congrats on > launching this! Someone is reading my mind :) > Hello Holmes, glad you like the status page! It's indeed great! > But is there any good source for historical data on incidents or re: the >

Re: [tor-dev] Question about hidden services shared by multiple hosts

David Goulet writes: > On 26 Mar (08:55:54), Holmes Wilson wrote: >> Hi everyone, > > Greetings, > >> >> We’re working on a peer-to-peer group chat app where peers connect over v3 >> onion addresses. >> >> One issue are groups where there are many users but only a few are online in >> a given

Re: [tor-dev] Proposal 328: Make Relays Report When They Are Overloaded

David Goulet writes: > Greetings, > > Attached is a proposal from Mike Perry and I. Merge requsest is here: > > https://gitlab.torproject.org/tpo/core/torspec/-/merge_requests/22 > Hello all, while working on this proposal I had to change it slightly to add a few more metrics and also to

[tor-dev] [RFC] Proposal: "Res tokens: Anonymous Credentials for Onion Service DoS Resilience"

: 331-res-tokens-for-anti-dos.md Title: Res tokens: Anonymous Credentials for Onion Service DoS Resilience Author: George Kadianakis, Mike Perry Created: 11-02-2021 Status: Draft ``` +--+ +--+ | Token Issuer | | Onion

Re: [tor-dev] Trouble with onionperf visualize and S61 performance experiments

Karsten Loesing writes: > On 2020-11-03 17:16, Karsten Loesing wrote: >> On 2020-11-03 15:01, George Kadianakis wrote: >>> Hello Karsten, >> >> Hi George! > > Hi again! > >>> hope you are doing well! >>> >>> I've been working

Re: [tor-dev] [RFC] Proposal: A First Take at PoW Over Introduction Circuits

George Kadianakis writes: > tevador writes: > >> Hi all, >> Hello, I have pushed another update to the PoW proposal here: https://github.com/asn-d6/torspec/tree/pow-over-intro I also (finally) merged it upstream to torspec as proposal #327: https://github.com/torpr

Re: [tor-dev] [RFC] Proposal: A First Take at PoW Over Introduction Circuits

tevador writes: > Hi all, > Hello tevador, thanks so much for your work here and for the great simulation. Also for the hybrid attack which was definitely missing from the puzzle. I've been working on a further revision of the proposal based on your comments. I have just one small question I

Re: [tor-dev] Safe Alternative Uses of Onion Service Keys

Matthew Finkel writes: > Hello everyone, > Hello hello! These are all good questions and they become more and more important as the onionspace grows and more use cases appear. > > > For computing the blinded key, the first 32 bytes of the long-term > secret key (LH) are multiplied with a

Re: [tor-dev] [RFC] Proposal: A First Take at PoW Over Introduction Circuits

troduction Circuits Author: George Kadianakis, Mike Perry, David Goulet Created: 2 April 2020 Status: Draft 0. Abstract This proposal aims to thwart introduction flooding DoS attacks by introducing a dynamic Proof-Of-Work protocol that occurs over introduction circuits. 1. Motivation

Re: [tor-dev] Onion Client Auth on v3 descriptor via Control port

Miguel Jacq writes: > Hi George, > > On Wed, Jun 17, 2020 at 12:37:18PM +0300, George Kadianakis wrote: >> >> Hmm, this is a bit embarassing for both of us, but if I'm not mistaken >> ONION_CLIENT_AUTH_ADD only controls the client-side of client auth >> creden

Re: [tor-dev] Onion Client Auth on v3 descriptor via Control port

Miguel Jacq writes: > Hi, > > I'm one of the OnionShare developers, looking at what can be done to support > Client Auth with v3 onions. > > OnionShare depends on Stem for all its interaction setting up ephemeral > onions, so we need Stem to support that fierst. > > So I have been working on

Re: [tor-dev] [RFC] Proposal: A First Take at PoW Over Introduction Circuits

fter we do some number crunching and see where we are at in terms of verification time and attack models. Thanks a lot! :) --- Filename: xxx-pow-over-intro-v1 Title: A First Take at PoW Over Introduction Circuits Author: George Kadianakis, Mike Perry, David Goulet Created: 2 April 2020 Status

Re: [tor-dev] [RFC] Proposal: A First Take at PoW Over Introduction Circuits

dvantage. Looking forward to more feedback! = And here comes the updated proposal: Filename: xxx-pow-over-intro-v1 Title: A First Take at PoW Over Introduction Circuits Author: George Kadianakis, Mike Perry, David Goulet Created: 2 April 2020 Status: Draft 0. Abstract This proposal aims

Re: [tor-dev] Does a design document for the DoS subsystem exist?

Lennart Oldenburg writes: > Hi all, > > We are investigating how Tor protects itself against Denial-of-Service > (DoS) attacks. So far, it has been difficult to find a comprehensive > top-level design document for the DoS subsystem (e.g., a torspec or > proposal) that reflects the decisions that

[tor-dev] [RFC] Proposal: A First Take at PoW Over Introduction Circuits

git repo: https://github.com/asn-d6/torspec/tree/pow-over-intro Cheers and stay safe! --- Filename: xxx-pow-over-intro-v1 Title: A First Take at PoW Over Introduction Circuits Author: George Kadianakis Created: 2 April 2020 Status: Draft 0. Abstract This proposal aims to thwart introduction

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

George Kadianakis writes: > 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 t

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

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

Re: [tor-dev] Request for onionbalance v3 pre-alpha testing

George Kadianakis writes: > George Kadianakis writes: > >> Hello list, >> >> we've been developing Onionbalance v3 for the past months, and I'm >> pretty hyped to say that the project has reached a stability point that >> could benefit from some initia

Re: [tor-dev] CVE-2020-8516 Hidden Service deanonymization

David Goulet writes: > On 04 Feb (19:03:38), juanjo wrote: > > Greetings! > >> Since no one is posting it here and talking about it, I will post it. >> >> https://nvd.nist.gov/vuln/detail/CVE-2020-8516 >> >> The guy: >>

Re: [tor-dev] Request for onionbalance v3 pre-alpha testing

George Kadianakis writes: > Hello list, > > we've been developing Onionbalance v3 for the past months, and I'm > pretty hyped to say that the project has reached a stability point that > could benefit from some initial testing by curious and adventurous > developers and user

[tor-dev] Request for onionbalance v3 pre-alpha testing

Hello list, we've been developing Onionbalance v3 for the past months, and I'm pretty hyped to say that the project has reached a stability point that could benefit from some initial testing by curious and adventurous developers and users. The project is not yet ready for proper use in actual

Re: [tor-dev] HSv3 descriptor work in stem

Hello Damian, I reported a bug report here: https://trac.torproject.org/projects/tor/ticket/31823#comment:19 I just reopened the old trac ticket but I think this is suboptimal. Would you prefer me to open new tickets in the future, or maybe open an issue on Github? I can do whatever is

Re: [tor-dev] Raising exceptions in add_event_listener() threads (was Re: HSv3 descriptor work in stem)

Damian Johnson writes: > Thanks George, this is a great question! I've expanded our tutorial to > hopefully cover this a bit better... > > https://stem.torproject.org/tutorials/tortoise_and_the_hare.html#advanced-listeners > Thanks both for this information! It was very useful! I basically

[tor-dev] Onion DoS: Killing rendezvous circuits over the application layer

Greetings! This is another thread [0] about onion service denial-of-service attacks. It has long been suggested that onion service operators should be given the option to kill spammy rendezvous circuits at will if they feel they are causing too much damage. Right now this is possible using the

[tor-dev] Raising exceptions in add_event_listener() threads (was Re: HSv3 descriptor work in stem)

Hello Damian (and list), here is another question about an issue I have encountered while developing onionbalance v3. In particular, I'm fetching HS descriptors using HSFETCH and then adding an add_event_listener() event to a function that does the descriptor parsing and handling as follows:

Re: [tor-dev] Practracker regen in #30381

teor writes: > Hi George, David, > > It looks like you regenerated the whole practracker file in #30381: > https://trac.torproject.org/projects/tor/ticket/30381 > https://github.com/torproject/tor/commit/53ac9a9a91a8f2ab45c75550456716074911e685#diff-9fd3400f062c4541d79881e199fd9e1f > > But we

Re: [tor-dev] Acceptable clock skew in tor 0.4.1

intrigeri writes: > Hi, > > recently, tor has become more tolerant to skewed system clocks; > great, thanks! > > At Tails, we would like to take advantage of these improvements in > order to remove as much as we can of our not-quite-safe clock fixing > code. Our testing suggests that: > > - A

Re: [tor-dev] HSv3 descriptor work in stem

George Kadianakis writes: > Damian Johnson writes: > >> Thanks George! Yup, work on that branch is in progress: >> >> https://gitweb.torproject.org/user/atagar/stem.git/log/?h=hsv3 > > Hello Damian, > > thanks for the reply here! I'm now back and ready to s

Re: [tor-dev] HSv3 descriptor work in stem

Damian Johnson writes: > Thanks George! Yup, work on that branch is in progress: > > https://gitweb.torproject.org/user/atagar/stem.git/log/?h=hsv3 Hello Damian, thanks for the reply here! I'm now back and ready to start working again on onionbalance/stem. What is your plan with the hsv3

Re: [tor-dev] HSv3 descriptor work in stem

Damian Johnson writes: >>Can I use `_descriptor_content()` to do that? Or should I call >>`_descriptor_content()` to generate the whole thing _without_ the >>sig, and then do the signature computation on its result and >>concatenate it after? > > Hi George. Yup, to create a

Re: [tor-dev] Optimistic SOCKS Data

David Goulet writes: > On 08 Oct (19:49:34), Matthew Finkel wrote: >> On Wed, Oct 2, 2019 at 5:46 PM Nick Mathewson wrote: >> > >> > On Fri, Sep 27, 2019 at 1:35 PM Tom Ritter wrote: >> > > >> > > On Mon, 5 Aug 2019 at 18:33, Tom Ritter wrote: >> > > > >> > > > On Tue, 2 Jul 2019 at 09:23,

[tor-dev] HSv3 descriptor work in stem

Hello atagar, I'm starting this thread to ask you questions about stem and the HSv3 work we've been doing over email so that we don't do it over IRC. Here is an initial question: I'm working on HSv3 descriptor encoding, and I'm trying to understand how `_descriptor_content()` works. In

[tor-dev] Exposing onion service errors to Tor Browser

Hello list, we've recently been thinking about how to expose onion-service-related errors to Tor Browser so that we can give more useful error pages to users. We currently return "Unable to connect" error pages for any kind of onion service error, and I think we can do better. This is a thread

Re: [tor-dev] [prop305] Introduction Point Behavior

David Goulet writes: > Greetings, > > This is part of the many discussions about proposal 305 which is the > ESTABLISH_INTRO DoS defenses cell extension. > > Implementation is close to done and under review in ticket #30924. However, > there is one part that is yet to be cleared out. asn and I

[tor-dev] Status of open circuit padding tickets

Hello Nick and Mike, here is a summary of the current state of open circpad tickets, which I tried to tidy up today. These are all the tickets I had in my radar and I hope I didn't miss any. I will be on leave starting the day after tomorrow (25th) so I wanted to inform you of the status quo:

Re: [tor-dev] Fwd: Re: Onion Service - Intropoint DoS Defenses

juanjo writes: > Forwarded Message > Subject: Re: [tor-dev] Onion Service - Intropoint DoS Defenses > Date: Thu, 4 Jul 2019 20:38:48 +0200 > From: juanjo > To: David Goulet > > > > These experiments and final note confirm what I thought about this rate

Re: [tor-dev] Onion Service - Intropoint DoS Defenses

David Goulet writes: > On 30 May (09:49:26), David Goulet wrote: >> Greetings! > > [snip] > > Hi everyone, > > I'm writing here to update on where we are about the introduction rate > limiting at the intro point feature. > > The branch of #15516 (https://trac.torproject.org/15516) is ready to be

Re: [tor-dev] Proposal for PoW DoS defenses during introduction (was Re: Proposal 305: ESTABLISH_INTRO Cell DoS Defense Extension)

juanjo writes: > On 13/6/19 12:21, George Kadianakis wrote: >> Is this a new cell? What's the format? Are these really keys or are they >> just nonces? > > Yes sorry, they are nonces. > > > This was only a proposal for a proposal. > >> Is this a new cell? W

[tor-dev] Proposal for PoW DoS defenses during introduction (was Re: Proposal 305: ESTABLISH_INTRO Cell DoS Defense Extension)

juanjo writes: > Hello, this is my view of things, please be gentle as this is my first > proposal draft :) > Hello, thanks for working on this. IMO any proof-of-work introduction proposal can be seen as orthogonal to David's prop305 which is a rate-limiting proposal (even tho it's not named

Re: [tor-dev] Proposal 305: ESTABLISH_INTRO Cell DoS Defense Extension

David Goulet writes: > Filename: 305-establish-intro-dos-defense-extention.txt > Title: ESTABLISH_INTRO Cell DoS Defense Extension > Author: David Goulet, George Kadianakis > Created: 06-June-2019 > Status: Draft > Thanks for this proposal, it's most excellent and an essent

Re: [tor-dev] Onion Service - Intropoint DoS Defenses

David Goulet writes: > Greetings! > > > Hello, I'm here to brainstorm about this suggested feature. I don't have a precise plan forward here, so I'm just talking. > Unfortunately, our circuit-level flow control does not apply to the > service introduction circuit which means that the intro

Re: [tor-dev] Proposal 304: Extending SOCKS5 Onion Service Error Codes

David Goulet writes: > Filename: 304-socks5-extending-hs-error-codes.txt > Title: Extending SOCKS5 Onion Service Error Codes > Author: David Goulet, George Kadianakis > Created: 22-May-2019 > Status: Open > Merged to torsp

Re: [tor-dev] Onion Service - Intropoint DoS Defenses

George Kadianakis writes: > George Kadianakis writes: > >> juanjo writes: >> >>> Ok, thanks, I was actually thinking about PoW on the Introduction Point >>> itself, but it would need to add a round trip, like some sort of >>> "authentication

Re: [tor-dev] Onion Service - Intropoint DoS Defenses

George Kadianakis writes: > juanjo writes: > >> Ok, thanks, I was actually thinking about PoW on the Introduction Point >> itself, but it would need to add a round trip, like some sort of >> "authentication based PoW" before allowing to send the INTRODUCE

Re: [tor-dev] Onion Service - Intropoint DoS Defenses

juanjo writes: > Ok, thanks, I was actually thinking about PoW on the Introduction Point > itself, but it would need to add a round trip, like some sort of > "authentication based PoW" before allowing to send the INTRODUCE1 cell. > At least it would make the overhead of clients higher than

Re: [tor-dev] Proposal 302: Hiding onion service clients using WTF-PAD

David Goulet writes: > On 16 May (14:20:05), George Kadianakis wrote: > > Hello! > >> 4.1. A dive into general circuit construction sequences [CIRCCONSTRUCTION] >> >>In this section we give an overview of how circuit construction looks like >>to a

Re: [tor-dev] Proposal 302: Hiding onion service clients using WTF-PAD

Tom Ritter writes: > On Thu, 16 May 2019 at 11:20, George Kadianakis wrote: >> 3) Duration of Activity ("DoA") >> >> The USENIX paper uses the period of time during which circuits send and >> receive cells to distinguish ci

[tor-dev] Proposal 302: Hiding onion service clients using WTF-PAD

Filename: 302-padding-machines-for-onion-clients.txt Title: Hiding onion service clients using padding Author: George Kadianakis, Mike Perry Created: Thursday 16 May 2019 Status: Accepted Ticket: #28634 0. Overview Tor clients use "circuits" to do anonymous communications. There a

Re: [tor-dev] [RFC] control-spec: Specify add/remove/view client auth commands (client-side).

George Kadianakis writes: > Hello list, > > here is a control spec patch for adding v3 client auth commands to > add/remove/view clients from the client-side (so Tor Browser -> Tor): > > https://github.com/torproject/to

Re: [tor-dev] [RFC] control-spec: Specify add/remove/view client auth commands (client-side).

Mark Smith writes: > On 5/6/19 11:19 AM, George Kadianakis wrote: >> Hello list, >> >> here is a control spec patch for adding v3 client auth commands to >> add/remove/view clients from the client-side (so Tor Browser -> Tor): >> >> htt

[tor-dev] [RFC] control-spec: Specify add/remove/view client auth commands (client-side).

Hello list, here is a control spec patch for adding v3 client auth commands to add/remove/view clients from the client-side (so Tor Browser -> Tor): https://github.com/torproject/torspec/pull/81/commits/3a26880e80617210b4729f96664ef9f0345b0b7c I'm currently unhappy with the

[tor-dev] Denial of service defences for onion services

Hello list, This is a thread summarizing and brainstorming various defences about denial of service defences for onion services after an in-depth discussion with David Goulet. We've been thinking about denial of service defences for onion services lately. This has been a recurrent topic that

Re: [tor-dev] prob_distr.c: LogLogistic fails stochastic tests on 32-bits mingw

George Kadianakis writes: > Hello Riastradh, > > as discussed on IRC, Appveyor recently started failing the stochastic > tests of LogLogistic on 32-bit builds: > https://github.com/torproject/tor/pull/576 > https://ci.appveyor.com/project/torproject/tor/builds/2089

[tor-dev] prob_distr.c: LogLogistic fails stochastic tests on 32-bits mingw

Hello Riastradh, as discussed on IRC, Appveyor recently started failing the stochastic tests of LogLogistic on 32-bit builds: https://github.com/torproject/tor/pull/576 https://ci.appveyor.com/project/torproject/tor/builds/20897462 I managed to reproduce the breakage by cross-compiling

[tor-dev] Updates and review on "Proposal 254: Padding Negotiation"

Hey Mike, I took another look at prop#254 and made some changes of my own in my torspec branch circuitpadding-proposal-updates (see commit ab37543). Let me know if they look right to you. Some of those I had to look into the code to understand, and I hope I got them right. Furthermore, I opened

Re: [tor-dev] Temporary hidden services

Michael Rogers writes: > On 18/10/2018 13:26, George Kadianakis wrote: >> Michael Rogers writes: >> >>> Hi George, >>> >>> On 15/10/2018 19:11, George Kadianakis wrote: >>>> Nick's trick seems like a reasonable way to avoid the issu

Re: [tor-dev] Temporary hidden services

Michael Rogers writes: > Hi all, > > The Briar team is working on a way for users to add each other as > contacts by exchanging links without having to meet in person. > > We don't want to include the address of the user's long-term Tor hidden > service in the link, as we assume the link may be

Re: [tor-dev] State of the HA proxy onion patch

Mahrud S writes: > Hi George, > > I think it looks good. Only comment I have is that it would be nice to have > an option to change the ipv6 subset, though I imagine people who would use > it can easily recompile with their own setting. > Agreed. IMO we should open a ticket about making the

Re: [tor-dev] State of the HA proxy onion patch

Mahrud S writes: > Hi George, > > I was trying to find a way to use the virtual port (i.e. > blahblah.onion:*port*) as dst_port, but I couldn't find a suitable in time. > For our purposes specifically, we only needed virtual port 443 for https, > so I hard-coded 443 in an almost identical branch

[tor-dev] State of the HA proxy onion patch

Hello Mahrud, I wanted to ask if you've been using the #4700 branch and how is it going? We've been planning to include #4700 in the upcoming 0.3.5 release if possible, and we remember that you had some pending patches to it. Do you think you can publish those somewhere if they are to be

Re: [tor-dev] Alternative directory format for v3 client auth

George Kadianakis writes: > George Kadianakis writes: > >> Hello haxxpop and David, >> >> here is a patch with an alternative directory format for v3 client auth >> crypto key bookkeeping as discussed yesterday on IRC: >>https://github.com/tor

Re: [tor-dev] Alternative directory format for v3 client auth

George Kadianakis writes: > Hello haxxpop and David, > > here is a patch with an alternative directory format for v3 client auth > crypto key bookkeeping as discussed yesterday on IRC: >https://github.com/torproject/torspec/pull/23 > > Thanks for making me edit the

Re: [tor-dev] Reviewing Trac #18642 (Teach the OOM handler about the DNS cache)

n...@neelc.org writes: > Hi tor-dev@ mailing list, > > I have a patch for Bug #18642 (Teach the OOM handler about the DNS cache) > which I would like reviewed. > > The URL is here: https://trac.torproject.org/projects/tor/ticket/18642 > (https://trac.torproject.org/projects/tor/ticket/18642) >

Re: [tor-dev] WTF-PAD and the future

Mike Perry writes: > George Kadianakis: >> Hello Mike, >> >> I had a talk with Marc and Mohsen today about WTF-PAD. I now understand >> much more about WTF-PAD and how it works with regards to histograms. I >> think I might even understand enough to start s

[tor-dev] WTF-PAD and the future

Hello Mike, I had a talk with Marc and Mohsen today about WTF-PAD. I now understand much more about WTF-PAD and how it works with regards to histograms. I think I might even understand enough to start some sort of conversation about it: Here are some takeaways: 1) Marc and Mohsen think that

Re: [tor-dev] Alternative directory format for v3 client auth

Alex Xu writes: > Quoting George Kadianakis (2018-07-11 19:26:06), as excerpted >> Michael Rogers writes: >> >> > On 11/07/18 14:22, George Kadianakis wrote: >> >> Michael Rogers writes: >> >> >> > First, Ed25519-

Re: [tor-dev] HS v3 client authorization types

David Goulet writes: > On 18 May (19:03:09), George Kadianakis wrote: >> Ian Goldberg writes: >> >> > On Thu, May 10, 2018 at 12:20:05AM +0700, Suphanat Chunhapanya wrote: >> >> On 05/09/2018 03:50 PM, George Kadianakis wrote: >> >> > b) We mi

Re: [tor-dev] Alternative directory format for v3 client auth

Michael Rogers writes: > On 11/07/18 14:22, George Kadianakis wrote: >> Michael Rogers writes: >> >>> On 10/07/18 19:58, George Kadianakis wrote: >>>> here is a patch with an alternative directory format for v3 client auth >>>> cryp

Re: [tor-dev] Alternative directory format for v3 client auth

Michael Rogers writes: > On 10/07/18 19:58, George Kadianakis wrote: >> here is a patch with an alternative directory format for v3 client auth >> crypto key bookkeeping as discussed yesterday on IRC: >>https://github.com/torproject/torspec/pull/23 >> &

[tor-dev] Alternative directory format for v3 client auth

Hello haxxpop and David, here is a patch with an alternative directory format for v3 client auth crypto key bookkeeping as discussed yesterday on IRC: https://github.com/torproject/torspec/pull/23 Thanks for making me edit the spec because it made me think of various details that had to

[tor-dev] The case with Tor2Web

Hello! It's a semi-secret that tor2web traffic has been blocked from the Tor network when we introduced the DoS subsystem this March [0]. The reason is that a big part of the DoS traffic was coming from one-hop clients continuously hammering onion services. This is something that we've been

Re: [tor-dev] DoH over non-HTTPS onion v3

nusenu writes: > Hi, > > this is just a short heads-up. > > I'm currently tinkering about how we could > improve DNS security and privacy for tor clients. My idea write-up is not done > yet but since the IETF DoH WG [1] is proceeding towards their next steps > I wanted to move now before it

[tor-dev] Proposal 292: Mesh-based vanguards

in the short term future. Until then, feel free to experiment with it if you feel like it. Check out the proposal and code and let us know if you have any questions or feedback! Thanks! --- Filename: 292-mesh-vanguards.txt Title: Mesh-based vanguards Authors: George Kadianakis and Mike Perry Created

Re: [tor-dev] HS v3 client authorization types

Ian Goldberg <i...@cs.uwaterloo.ca> writes: > On Thu, May 10, 2018 at 12:20:05AM +0700, Suphanat Chunhapanya wrote: >> On 05/09/2018 03:50 PM, George Kadianakis wrote: >> > b) We might also want to look into XEdDSA and see if we can potentially >> >use the

Re: [tor-dev] HS v3 client authorization types

Suphanat Chunhapanya <haxx@gmail.com> writes: > On 05/09/2018 03:50 PM, George Kadianakis wrote: >> I thought about this some more and discussed it with haxxpop on IRC. In >> the end, I think that perhaps starting with just desc auth and then in >> the future impl

Re: [tor-dev] Proposal #291 (two guards) IRC meeting Wed Apr 18, 17:00 UTC

Mike Perry writes: > Mike Perry: >> Heyo. >> >> We're going to have a meeting to discuss Proposal 291. See this thread: >> https://lists.torproject.org/pipermail/tor-dev/2018-April/013053.html > > Ok, we had this meeting. High level (ammended) action items are: > > 1.

Re: [tor-dev] HS v3 client authorization types

George Kadianakis <desnac...@riseup.net> writes: > Suphanat Chunhapanya <haxx@gmail.com> writes: > >> Hi, >> >> On 04/28/2018 06:19 AM, teor wrote: >>>> Or should we require the service to enable both for all clients? >>>> >

Re: [tor-dev] Proposal #291 Properties (was IRC meeting)

Mike Perry writes: > Mike Perry: >> teor: >> > >> > >> > > On 25 Apr 2018, at 18:30, Mike Perry wrote: >> > > >> > > 1. Hidden service use can't push you over to an unused guard (at all). >> > > 2. Hidden service use can't influence your

Re: [tor-dev] HS v3 client authorization types

Suphanat Chunhapanya writes: > Hi, > > On 04/28/2018 06:19 AM, teor wrote: >>> Or should we require the service to enable both for all clients? >>> >>> If you want to let the service be able to enable one while disable the >>> other, do you have any opinion on how to

Re: [tor-dev] onion v2 deprecation plan?

Jonathan Marquardt writes: > On Wed, Apr 25, 2018 at 04:58:36PM -0400, grarpamp wrote: >> In onionland, there seems to be little knowledge of v3, thus little worry >> about v2 in cases where v3 would actually apply to benefit, that's bad. > > v3 onion services just seem like a

Re: [tor-dev] Proposal #291 Properties (was IRC meeting)

Mike Perry writes: > Mike Perry: >> Mike Perry: >> > Heyo. >> > >> > We're going to have a meeting to discuss Proposal 291. See this thread: >> > https://lists.torproject.org/pipermail/tor-dev/2018-April/013053.html >> >> 3. Describe adversary models for our variant

Re: [tor-dev] onion v2 deprecation plan?

nusenu writes: > Hi, > > even though you are probably years away from deprecating onion v2 services > it is certainly good to have a clear plan. > > I'm asking because the sooner onion v2 are deprecated the sooner some > people can stop worrying about malicious HSDirs.

Re: [tor-dev] HS desc replay protection and ed25519 malleability

isis agora lovecruft <i...@torproject.org> writes: > Ian Goldberg transcribed 2.5K bytes: >> On Wed, Apr 18, 2018 at 04:53:59PM +0300, George Kadianakis wrote: >> > Thanks for the help! >> > >> > Hmm, so everyone gets a shot at a single malleability &q

Re: [tor-dev] ahmia ~ summer of privacy

Stelios Barberakis writes: > Hello all, > > My name is Stelios and I am a CS student at Technical University of Crete. > This summer I will be working on ahmia project, during > the "summer of privacy". > > This will be the first time to be engaged with the

Re: [tor-dev] Proposal #291 (two guards) IRC meeting Wed Apr 18, 17:00 UTC

Mike Perry writes: > Mike Perry: >> Heyo. >> >> We're going to have a meeting to discuss Proposal 291. See this thread: >> https://lists.torproject.org/pipermail/tor-dev/2018-April/013053.html > > Ok, we had this meeting. High level (ammended) action items are: > > 1.

Re: [tor-dev] HS desc replay protection and ed25519 malleability

Watson Ladd <watsonbl...@gmail.com> writes: > On Wed, Apr 18, 2018 at 6:15 AM, George Kadianakis <desnac...@riseup.net> > wrote: >> Hello Ian, isis, and other crypto people around here! >> >> Here is an intro: In HSv3 we've been using revision counters

[tor-dev] HS desc replay protection and ed25519 malleability

Hello Ian, isis, and other crypto people around here! Here is an intro: In HSv3 we've been using revision counters (integers++) to do HS desc replay protection, so that bad HSDirs cannot replay old descs to other HSDirs. We recently learned that this is a bad idea from a scalability prespective

Re: [tor-dev] Proposal: The move to two guard nodes

Mike Perry writes: > In-line below for ease of comment. Also available at: > https://gitweb.torproject.org/user/mikeperry/torspec.git/tree/proposals/xxx-two-guard-nodes.txt?h=twoguards > > === > > Filename: xxx-two-guard-nodes.txt > Title: The

Re: [tor-dev] Proposal: The move to two guard nodes

Mike Perry writes: > In-line below for ease of comment. Also available at: > https://gitweb.torproject.org/user/mikeperry/torspec.git/tree/proposals/xxx-two-guard-nodes.txt?h=twoguards > > === > > Filename: xxx-two-guard-nodes.txt > Title: The

Re: [tor-dev] Setting NumEntryGuards=2

Mike Perry writes: > [ text/plain ] > Back in 2014, Tor moved from three guard nodes to one guard node: > https://blog.torproject.org/improving-tors-anonymity-changing-guard-parameters > https://trac.torproject.org/projects/tor/ticket/12206 > > We made this change

Re: [tor-dev] Setting NumEntryGuards=2

David Goulet <dgou...@torproject.org> writes: > [ text/plain ] > On 22 Mar (13:46:36), George Kadianakis wrote: >> Mike Perry <mikepe...@torproject.org> writes: >> >> > [ text/plain ] >> > Back in 2014, Tor moved from three guard nodes to

Re: [tor-dev] Setting NumEntryGuards=2

Mike Perry writes: > [ text/plain ] > Back in 2014, Tor moved from three guard nodes to one guard node: > https://blog.torproject.org/improving-tors-anonymity-changing-guard-parameters > https://trac.torproject.org/projects/tor/ticket/12206 > > We made this change

Re: [tor-dev] Enhancement for Tor 0.3.4.x

Nick Mathewson writes: > [ text/plain ] > On Mon, Feb 12, 2018 at 2:32 PM, David Goulet wrote: >> Hello everone! >> >> As an effort to better organize our 0.3.4.x release for which the merge >> window >> opens in 3 days (Feb 15th, 2018), we need to

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

Georg Koppen <g...@torproject.org> writes: > [ text/plain ] > 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 L

Re: [tor-dev] Starting with contributing to Anonymous Local Count Statistics.

na.maury...@gmail.com> > wrote: > >> >> -- Forwarded message -- >> From: George Kadianakis <desnac...@riseup.net> >> Date: Wed, Jan 31, 2018 at 6:32 PM >> Subject: Re: [tor-dev] Starting with contributing to Anonymous Local Count >> Statistics. >> To: Arun

  1   2   3   4   5   >