[GNU/consensus] Fwd: [SocialSwarm-D] Kill the pseudonyms just to handle sybil attacks?

[hellekin]

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 <***@time.to.swarm.psyced.org>
To: socialswarm-***@ml.foebud.org

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 ***@digitalcourage.de

[Michael Rogers]

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

Post by hellekin
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
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.
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
https://socialswarm.net/ https://wiki.socialswarm.net/ Liquid
Feedback: https://socialswarm.tracciabi.li/
Digitalcourage, Bielefeld, Germany

[Christian Grothoff]

The real issue is a different one:

How do you distinguish the claim of a Sybil attacker that he (and his
100 Sybils) were present and that 10 good peers were absent, from the
counter-claim that the 10 good peers were present and the Sybils were
absent?

Decentralizing the choice of location and even privacy-preserving range
queries (who is close) are relatively easy to do with crypto, at least
by comparison ;-).

My 2 cents

Christian

Post by Michael Rogers
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

Post by hellekin
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
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.
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
https://socialswarm.net/ https://wiki.socialswarm.net/ Liquid
Feedback: https://socialswarm.tracciabi.li/
Digitalcourage, Bielefeld, Germany