[tor-talk] Propsal for decentralization of the Tor network

Christian Gagneraud chgans at gna.org
Mon Nov 24 03:59:20 UTC 2014


On 24/11/2014 4:17 p.m., Gregory Maxwell wrote:
> On Mon, Nov 24, 2014 at 3:03 AM, Cari Machet <carimachet at gmail.com> wrote:
>> prove decentralization creates vulnerability to a larger degree than
>> centralization
>
> You haven't specified the decentralization mechanism.  So I guess I get to pick?
>
> Okay. Instead of believing the directory authority signatures, instead
> you have nodes connect out to as many nodes as they can find, and add
> any entry returned by a majority of nodes to their local directory.
>
> Oops. The attacker is a local network and only lets them connect out
> to their own nodes, which perform a sybil attack and limit the tor
> client's view to just the attackers hosts.  Client security is lost
> completely.

Isn't it how I2P works? [1], with maybe the exception for bootstrapping 
where you need data from an existing (trusted) node.

[5 minutes later]

Actually according to [2]:
"We currently have not implemented any particular technique to address 
Sybil, but do include placeholder certificates in the router's and 
destination's data structures which can contain a HashCash certificate 
of appropriate value when necessary (or some other certificate proving 
scarcity)."

My 2 cents,
Chris

[1] https://geti2p.net/en/docs/how/network-database
[2] https://geti2p.net/en/docs/how/threat-model#sybil

>
> Q.E.D. ...
>
> There are many ways you can go about trying to be 'decentralized'
> most are _profoundly_ insecure in an active adversaries attack model.
> Usually the main failure mode is inadequate sybil resistance.
>
> This isn't to say that I don't think useful things are possible,  I
> don't know. I have not seen a proposal which even makes an argument
> for its own security for this application. Saying "decenteralized" is
> easy, tendering a concrete proposal which achieves useful security
> properties is much harder.  And "decenteralized" isn't something that
> can be deployed or analyzed for its security, specific concrete
> proposals are.
>
> Incidentally,
>
>> Ruh-roh, this is now necessary: This email is intended only for the
>> addressee(s) and may contain confidential information. If you are not the
>> intended recipient, you are hereby notified that any use of this
>> information, dissemination, distribution, or copying of this email without
>> permission is strictly prohibited.
>
> If you don't want your emails being made public you should consider
> not sending them to a public mailing list.
>


More information about the tor-talk mailing list