Well, friends, here’s an attack on the whole anonymization approach to
reporting HSDir (or other) statistics:
1. The adversary creates a large number of onion services that almost always
cover the entire set of HSDirs.
2. The adversary performs actions with his onion services that add to the
"A. Johnson" writes:
> Hello tor-dev,
>
>
>
> Two HS statistics that we (i.e. people working on Sponsor R) are interested
> in collecting are:
> 1. The number of descriptor fetches received by a hidden-service directory
> (HSDir)
> 2. The number of client introduction requests at an intro
> I am beginning to think that AnonStats2 is not secure enough to use.
But I have come up with a possible replacement. Let’s call it AnonStats3.
AnonStats3 works in conjunction with AnonStats1. It provides a rough estimate
of the statistic that probably is most useful as a sanity check on AnonSt
>> AnonStats1 doesn’t leak the relay identity. The relay probability is sent
>> over a separate circuit (at a random time). I intentionally did that just to
>> avoid the problem you describe.
>>
>
> Ah, I see, that makes sense.
>
> Some more notes from reading AnonStats1 then:
>
> a) How do r
"A. Johnson" writes:
> Hi George,
>
> Thanks for the really thoughtful comments.
>
>>> Two HS statistics that we (i.e. people working on Sponsor R) are interested
>>> in collecting are:
>>> 1. The number of descriptor fetches received by a hidden-service directory
>>> (HSDir)
>>> 2. The numbe
Hi George,
Thanks for the really thoughtful comments.
>> Two HS statistics that we (i.e. people working on Sponsor R) are interested
>> in collecting are:
>> 1. The number of descriptor fetches received by a hidden-service directory
>> (HSDir)
>> 2. The number of client introduction requests
"A. Johnson" writes:
> Hello tor-dev,
>
Hello,
and thanks for posting this to the list.
> While helping design ways to publish statistics about hidden services in a
> privacy-preserving
> manner, it has become clear to me that certain statistics cannot be safely
> reported using the
> curren
> I think that there are some details to work out, but the general
> approach you describe sounds reasonable. IMO it doesn't need to be
> directory authorities who are StatsAuths, and we could use a "blinded
> token once per relay per period" scheme for other stuff too down the
> line.
I wonder w
On Tue, Jan 6, 2015 at 12:14 PM, A. Johnson
wrote:
> Hello tor-dev,
>
> While helping design ways to publish statistics about hidden services in a
> privacy-preserving
> manner, it has become clear to me that certain statistics cannot be safely
> reported using the
> current method of having ea
Hello tor-dev,
While helping design ways to publish statistics about hidden services in a
privacy-preserving
manner, it has become clear to me that certain statistics cannot be safely
reported using the
current method of having each relay collect and report measurements. I am
going to describe
10 matches
Mail list logo
