Re: [tor-dev] HSDir hash ring modification

[Kang <td66bshwu@xxxxxxxxx>]

Sure.
This wasn't intended as a solution for the determinism problem.
Just a small defence against harvesting of Tor hidden service
descriptors by having each hidden service use a differently ordered
ring, so it wouldn't be possible, for instance to place a dishonest
node in every third position of the ring for all services.
I had slightly misunderstood home "time-period" was calculated.

For the determinism problem my current thoughts seem to be similar to
what's in the paper.
That you could use a simple bit commitment scheme to generate a random
value in a distributed fashion.

You could have each authority generate a random value, and then
encrypt it with a temporarily secret key.
They distribute the encrypted values and once each authority has the
full set they distribute the keys.
They'd then decrypt the values and combine them to create a salt which
would be used in descriptor-id calculations by clients and hidden
services for that time period.
They'd probably also have to sign the value and then distribute theses
signatures among themselves to ensure that they all had the same
value.

The problem with dishonest authorities affecting the outcome is indeed tricky.
With the above solution even if an authority can't change its value it
can refuse to unlock its value, leaving us with a few possible courses
of action, each flawed.
We could start the calculation all over again, which would mean a
dishonest node could simply keep refusing to unlock its value until
the desired outcome is achieved.
Alternatively you could simply drop the value and finish the
calculation without it. This would mean an attacker can choose between
(I think) C^2 different results, where C is the number of dishonest
collaborating authorities.
If you used a scheme where an encrypted value could be unlocked
without cooperation from its creator then this could potentially be
abused to modify the result very precisely, provided that there were
enough dishonest collaborators.

Any of these methods could be augmented using some kind of reputation
system, although this would need to be carefully designed as it's also
open to exploit.
A reputation system where an authority can either participate or can't
participate in the random value calculation probably isn't a good
idea, since an attacker could likely abuse this to have honest
authorities locked out.
If a reputation system were used I imagine a sliding scale would work
best, where the less trusted an authority is the less it can modify
the outcome, with even the most untrusted authorities having a small
say in the result.

On Sat, Aug 24, 2013 at 2:33 AM, Nick Mathewson <nickm@xxxxxxxxxxxx> wrote:
> On Fri, Aug 23, 2013 at 1:01 PM, Nick Mathewson <nickm@xxxxxxxxxxxx> wrote:
>
> See also Roger's writeup at
> https://trac.torproject.org/projects/tor/ticket/8244 ; it's pretty
> informative IMO.
> _______________________________________________
> tor-dev mailing list
> tor-dev@xxxxxxxxxxxxxxxxxxxx
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev