[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [GNU/consensus] Fwd: [SocialSwarm-D] Kill the pseudonyms just to han
From: |
Michael Rogers |
Subject: |
Re: [GNU/consensus] Fwd: [SocialSwarm-D] Kill the pseudonyms just to handle sybil attacks? |
Date: |
Mon, 30 Jun 2014 15:17:09 +0100 |
User-agent: |
Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 |
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
In its current form the proposal relies on a central entity that
collects registrations, schedules meetings and gives points to
identities that participate in meetings. I wonder whether the central
entity can be removed.
Cheers,
Michael
On 30/06/14 15:04, hellekin wrote:
> A very interesting contribution of Carlo on Sybil attacks and how
> to avoid them in an end-to-end system.
>
> == hk
>
>
> -------- Original Message -------- Subject: [SocialSwarm-D] Kill
> the pseudonyms just to handle sybil attacks? Date: Mon, 30 Jun 2014
> 13:57:50 +0200 From: carlo von lynX
> <address@hidden> To:
> address@hidden
>
> The scare that is being mounted concerning sybil attacks is making
> people think of radical solutions like impeding people to group
> their contacts into multiple identities, as described in
> http://forum.ethereum.org/discussion/1064/proposal-for-a-1-on-1-identity-system-protocol
>
> Unless you care to have a Faceboogle-like feature of enforcing
> one key for one person, that is not needed. Sybil attacks are a
> problem solved at least in the GNUnet DHT if not in other advanced
> DHTs out there.
>
> There is a very nice video of the 30c3 GNUnet Mesh presentation
> that is sitting on the c3voc server, waiting to be uploaded to
> http://cdn.media.ccc.de, that explains very well how sybil attack
> protection works - and it isn't even using any of the dozen social
> methods that have been proven to work in various papers.
>
> So if you see anyone promoting their server-hosted technologies
> mounting nasty sybil attacks on end-to-end technology in
> comparison hit them in the face with some well-nurtured facts.
>
>
> ++++ Content of the web page follows, so you don't have to expose
> your interest ++++
>
>
> Proposal for a 1-on-1 identity system protocol.
>
>
> Having an identity system that more or less guarantees that each
> person can only hold one identity at a time would allow many things
> that would otherwise be vounerable to sybil attacks to be built.
>
> The method i'm proposing relies on having meetings organized where
> people authenticate each other.
>
> Let's call the code/procedure an identity contract.
>
> It would work like this:
>
> 1. Register an name in the identity contract 2. Give your
> approximate positional data, this can be updated as you move
> around.
>
> 3. A few days before the date, participants in the contract are
> randomly grouped together based on location, and get invited to a
> channel to communicate a meeting point.
>
> 4. The people thus invited (maybe around 10-20 people, depending on
> how many are registered in this area) gather to the agreed upon
> meeting point.
>
> 5. At the meeting, each participant signs a statement saying who
> they met at the meeting, so that every person is signed by at least
> one other who was participating in this meetup.
>
> 6. The contract registers that the meeting was successful, and
> gives everyone involved one identity point.
>
> This protocol relies on the fact that you cannot be in two places
> at once, and as long as you participate in a majority of your
> meetings, everyone can be sure that the identity you chose is your
> only identity within this system.
>
> I have not been able to see any obvious attacks on this system,
> but maybe i'm missing out on something? Would love to hear your
> comments. -- SocialSwarm mailing lists:
> https://socialswarm.net/en/participate/ Websites:
> https://socialswarm.net/ https://wiki.socialswarm.net/ Liquid
> Feedback: https://socialswarm.tracciabi.li/
> Digitalcourage, Bielefeld, Germany
> address@hidden
>
>
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
iQEcBAEBCAAGBQJTsXFlAAoJEBEET9GfxSfMB7IH/1YUSWd6jnCPEJ03L6oWyOPY
Z13c/IBRSgOkyRHV1+nXhxJEO+R8VVcG4f5vRtax0JPAwsWWyGRt4vgrp9slG9Au
FO9MQYfggMuE5a7lWEZaKlWcuzzrU1SGPrleuxOpZAxnPVLinMMa7nij7Em1QdTE
s0QqhD9ZK34+G6ZW8yJX8mpEd89sc0099hblPMCYCebiJJGAWgczeHUrBfANZ4+n
uM16heS/a0SxaxytA6gyB4Xky1HLZ8ex98O5RmP1gHfX3gnE9L6wh9nOdD8dmkPm
N4GERY6qxFrukpapeMX4batZC+V8hl7JkIFwbSmhnHA4oOajEp0kNpk0jcYT8SQ=
=u6+U
-----END PGP SIGNATURE-----