[metrics-team] v3 unique onion address estimates

[Karsten Loesing]

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.

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.

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

Let's keep this in mind when we make plans for our next roadmap.

> Hope this help!
> David

It does, yes!

All the best,
Karsten

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 528 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/metrics-team/attachments/20191218/334bdfb5/attachment.sig>