[metrics-team] v3 unique onion address estimates

[Roman Brunner]

Thank you for the very detailed answer, also for the pointers!

I'm currently involved with a project that looks closer at the network
(the hyperlink network)
established between onion services. In order to have an estimate of
the number of
services, I used the v2 estimate before. As you detailed, this will
become less and less
useful, especially with the deprecation of the v2.

As I really look forward to seeing this feature implemented, I'll see
how far I cat get with
developing this feature.
But first I'll ready up on the issue

Cheers!

Roman

On Thu, 19 Dec 2019 at 15:13, David Goulet <dgoulet at torproject.org> wrote:
>
> On 18 Dec (21:49:13), Karsten Loesing wrote:
> > On 2019-12-18 17:04, David Goulet wrote:
> > > On 18 Dec (10:59:51), Roman Brunner wrote:
> > >> Hi metrics team,
> > >>
> > >> There exists an estimate for unique v2 .onion addresses for v2 onion
> > >> services. However, for v3, no such estimate exists.
> > >> Lately, the estimates for the v2 addresses started to decrease steadily,
> > >> which I assume to be because of more and more services make the switch to
> > >> v3. Hence it would be interesting to know how many distinct v3 addresses
> > >> are available.
> > >> Is there anything planned to extend this estimate to v3 addresses? And
> > >> towards a possible implementation for v3: do v3 addresses pose any
> > >> additional challenges compared to v2 or could the current statistics
> > >> collection be extended?
> > >
> > > Hi!
> > >
> > > So yes, v3 are more challenging. The reason is because with v3 descriptors
> > > (posted at the HS directory), do not contain the .onion address. They instead
> > > have what we call a "blinded key" which can only be derived depending on a
> > > time period, a shared random value (created within the consensus every 24h)
> > > and the master identity key of the service (the v3 .onion).
> > >
> > > And thus, the client can generated that blinded key by knowing the .onion and
> > > request the blinded key at the directory. One thing that is working for us,
> > > the time period are fixed over a day and we know when the shared random is
> > > created as well.
> > >
> > > Thus the only way we can estimate is by keeping an aggregate count of similar
> > > blinded keys a directory sees every 24h (up to the new shared random
> > > creation). And also, another complication, services publish 2 descriptors at
> > > all time that is using the current and previous shared random value in order
> > > to accomodate client with skewed clock.
> > >
> > > We'll be able to only estimate the number of v3 addresses that the network
> > > sees. And that that number will be obsfuscated for privacy reasons, like we do
> > > with v2.
> > >
> > > More info: https://trac.torproject.org/projects/tor/ticket/23126
> > >
> > > All in all, we haven't done this feature in tor just yet.
> >
> > Thanks, David, for summarizing the current state on the little-t-tor
> > side. I had started drafting a response to this question, and these
> > details about version 3 onion services were something I didn't know and
> > would have asked for your input anyway.
>
> Awesome summary Karsten from Metric side!
>
> >
> > So, assuming that that ticket above will be resolved some day, there are
> > still a few more steps until we have graphs on version 3 .onion addresses:
> >
> >  - We need to wait until enough relays have upgraded to the version that
> > reports version 3 .onion address counts. This can take weeks or even
> > months. Not the end of the world, but worth considering.
>
> To complement, on January 2020, the long term stable tor 0.2.9 will become end
> of life and we will start rejecting them from the network not long after.
>
> https://trac.torproject.org/projects/tor/ticket/32672
>
> This will _finally_ bring the end of relays not supporting onion service v3.
>
> >
> >  - We also need to extend the code that aggregates numbers for Tor
> > Metrics to also aggregate version 3 .onion address counts. It's not the
> > simplest aggregation code we have, so that this might take a week or two
> > of coding time.
> >
> >  - And we need to add or extend graphs to show the new numbers. This one
> > is rather simple. (We just added two graphs on BridgeDB requests, and
> > with phw's help that only took us two days of coding time.)
> >
> > It seems to me that adding estimates of version 3 .onion addresses won't
> > happen without funding. It's too much work that involves too many people
> > that it could be done between funded work.
> >
> > At the same time, doing this work seems to be getting more urgent, as
> > the version 2 numbers will become less useful over time. If we delay
> > this too much, we'll end up having no useful numbers on onion services
> > anymore.
>
> Yes true. And the removal of 029 from the network will allow us to start the
> deprecation path of v2. It is a long road but once it starts, the train won't
> be stoppable :).
>
> Cheers!
> David
>
> --
> AOrq46damX3clZogjR9FlXTru90GV9IT5Rq/J0EzVSA=
> _______________________________________________
> metrics-team mailing list
> metrics-team at lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/metrics-team