Okopipi Paper: First Draft
Journeyman
working with Kwinter to write up a paper on how everything is going to
work. We have finished our first draft and I think it pretty much
covers everything. If you have any questions, comments, suggestions,
or find any holes, please let us know and we can address them.
Viraptor
I just read the draft and I have some comments / ... thoughts.
When a client sends some kind of message to the okopipi network, it
should be forwarded by clients, until it hits the supernode. After that
it should be stopped - ok, that can be done in many ways...
But think about what happens in the first days - when there are only
few (thousands) of users. With big enough (100 clients if each has 10
peer connections) botnet anyone can:
- get almost complete list of clients
- send specific messages to single clients, and check which of them get
forwarded / broadcasted, and which don't (direct supernode hit), or
- guess which nodes originate the messages, because he can timestamp
all of them
- ...
- profit! ;)
Any ideas how to protect okopipi?
If that was already discussed - sorry - I couldn't find it.
Kevin Winter
>
> [Beware: speculations]
> I just read the draft and I have some comments / ... thoughts.
> When a client sends some kind of message to the okopipi network, it
> should be forwarded by clients, until it hits the supernode. After that
> it should be stopped - ok, that can be done in many ways...
First, let me mention that this is the "new" draft of okopipi. Nano
was working on a from scratch design for the original steering
committee; however, there has been minimal progress (the design is
incomplete), and many of the leaders are non-responsive to this
project. The draft that Journeyman and myself created is fairly new
(few days old). We want to make a simple design that would be easy to
implement. That's why we want to form the code from the GNUnet
project.
http://en.wikipedia.org/wiki/GNUnet
http://gnunet.org/
> But think about what happens in the first days - when there are only
> few (thousands) of users. With big enough (100 clients if each has 10
> peer connections) botnet anyone can:
> - get almost complete list of clients
Actually, they can't. GNUnet is based partly on anonymity. The idea
is that when you send a message, any given member of the group should
not be able to tell who the message came from, only where the message
is going. Deniability comes in the form that the internode
communications are encrypted with 256bit AES. This is relatively
strong, especially when used on every message. The encryption is
end-to-end, which means only the sender and receiver know who each
other are and possess the keys to decrypt the message.
Furthermore, we plan to use 2048bit keys to sign the message
(encrypting it would be overkill, and much more computationally
difficult with such a large key for even slightly large files) in
order to ensure authenticity. Every member will create a 2048 bit key
upon joining. This key will be submitted to a Super User for
approval. They will sign this key and send it back. Now, every time
this node sends a message, it will include its signed copy of its key,
and the message signed with this key. Since faking the SUs key will
be computationally infeasible we know that the node sending the
message is in direct contact with a Super User, creating a web of
trust.
> - send specific messages to single clients, and check which of them get
> forwarded / broadcasted, and which don't (direct supernode hit), or
> - guess which nodes originate the messages, because he can timestamp
> all of them
please check out this FAQ answer:
http://gnunet.org/faq.php3?xlang=English#speed
> - ...
> - profit! ;)
>
> Any ideas how to protect okopipi?
I believe GNUnet should take care of most problems :)
> If that was already discussed - sorry - I couldn't find it.
S'ok, no big deal.
Anyone else with questions should read over the GNUnet website,
wikipedia article and FAQ.
Based on a number of features, we feel GNUnet will provide okopipi
with a good solid base to start from, ultimately reducing development
time.
Please keep in mind that we are not experts on GNUnet yet. Our plan
is to firm up how we want okopipi to act, and once we know what we
want it to do, start coding. We'll start by looking over the codebase
of GNUnet, and immediately start porting the code to be as platform
agnostic as possible.
We'll also need some gui writers to make a simple (and later
increasingly complex) gui in perhaps gtk or another cross platform
toolkit.
If we find something infeasible upon code inspection and
implementation, we can always shift the design to accommodate.
~Kevin
--
Open Source, Open Mind
Viraptor
into acccount that I treat the spammer "attacker" as a really good
coder / security person, that targets okopipi only, which is...
nevermind ;)
> > - get almost complete list of clients
>
> Actually, they can't. GNUnet is based partly on anonymity. The idea
> is that when you send a message, any given member of the group should
> not be able to tell who the message came from, only where the message
> is going. Deniability comes in the form that the internode
Starting, I get some IPs of people in p2p network. Let's say I get 10
clients on p2p net from different nets. Some peers' IPs that I get may
overlap, some won't, but I know, they're clients and know nothing more
about them. I can't read their messages.
[cut quote: end-to-end sign / encryption]
[repeat quote: messages in network]
> not be able to tell who the message came from, only where the message
> is going.
I know also which client relayed it to me -> he sent HELLO, PING, PONG,
MESSAGE, ... etc. He could also create the message, but not I can't
tell the difference, because it's encrypted for SU only.
> > - send specific messages to single clients, and check which of them get
> > forwarded / broadcasted, and which don't (direct supernode hit), or
Ok - not I've just seen the solution - just make the supernode relay
messages in normal way...
> > - guess which nodes originate the messages, because he can timestamp
> > all of them
Suppose, that attacker has nodes A1, A2, A3, ..., clients are Cx, ...
supernodes Sx, ...
Attacker has many nodes (many = ~ 1/20 of clients). A2, A3, ... know
pub and priv key of A1, so they know if they get message for A1.
A1 sends a message to S1, that will need some response. Now S1 sends
its response to A1. Some Ax nodes will get it, some won't.
All the Ax nodes are NTP synchronized.
- A2, A3 get messages first from C1.
- Then A4 gets message from C2.
Some other Ax get the message from Cx. Attacker collects timestamps and
compares.
Now we have:
+5% for C1==S1
+100% for C2 and every other node Cx that sent that message after C1,
that Cx!=S1
Further analysis -> we know general timing of part of the network. Now
reconnect all Ax nodes and get new peer pools. Send message to S1 and
wait for reply.
After some iterations try to DDOS most probable S1 node and see if it
was correct guess.
This one is tricky, as some host has to originate the S1 response.
Depending on p2p network size, it can be identified sooner, or later.
But if S1 won't change it's IP, it will be identified in a reasonable
time.
I can't find any point in draft or gnunet, that protects this kind of
attack. Maybe supernodes exchanging their keys and roles with each
other could be some help, but I'm not sure.
Comments?
Kevin Winter
How do you mean DDoS? Ping? ignore it. Lots of "valid" requests?
Won't work. Did you read the links? The other nice bonus of GNUnet
is the accounting feature. Every node starts with x amount of trust.
Everything they request reduces the amount of trust, every request
they answer builds their trust. Therefore if a node runs out of
trust, their requests get served last. Priority is given to nodes
with highest trust. Therefore a normally behaving node, which stores
spam (more trust) will have a high amount of trust for making new
requests which will be answered, whereas a misbehaving node will have
zero trust, and therefore the lowest priority to answer. Also note
that requests are dropped (no queues) when a node is too busy and the
trust level of the request is too low.
> This one is tricky, as some host has to originate the S1 response.
> Depending on p2p network size, it can be identified sooner, or later.
> But if S1 won't change it's IP, it will be identified in a reasonable
> time.
>
> I can't find any point in draft or gnunet, that protects this kind of
> attack. Maybe supernodes exchanging their keys and roles with each
> other could be some help, but I'm not sure.
> Comments?
The way i envision Super nodes working is like so:
A list of Supernodes is made, with node ID and public key both signed
by the supernode. This list is in turn signed by a project admin (if
we can't trust a project admin, who can we trust?). This list can be
obtained from anyway, but in particular from the okopipi website and
other mirrors. We'll have each list timestamped and only valid for an
horu or so. In this way, ANY node can know the nodeid and public key
of a supernode. Due to trust, targeted specific supernodes will have
little effect, since trust will quickly be depleted and then dropped.
I don't beleive that DDoS'ing a SU will be effective for a number of
reasons. There will be many supernodes. one node going down won't
affect the viability of the network. Due to trust, an attack can only
go on for so long. Standard firewalls will take care of most DDoS
attacks. The only remaining one will be resource starvation, which is
limited by trust. A busy SU will start dropping requests from
EVERYONE until it is less busy, hence throttling an attack. Also, due
to the nature of the routing, unless the attacking nodes are direct
neighbors of the SU, the attack can only proceed at a speed dictated
by the network. Since GNUnet inserts timing delays to break timing
attacks the attack will be massively slowed.
Please read the links i provided, especially the FAQ. Many of these
questions are answered there.
Again, the point of this draft is to determine how okopipi will work.
Basic security is being considered, and specific attacks will be
solved when we begin implementing.
nano
Please don't settle on that issue. It would probably be possible to
implement this on top of GNUnet. The problem lies in the ability for a
bad node to route messages correctly for 99.9% of messages, but drop
the 0.1% of messages that fit a certain profile (reporting a spam
message that it doesn't want to be reported, for instance).
nano
implementation. I would look into its feasability as a storage
solution. Storing data on only a few servers connected to the network
through one or more supernodes leaves the network open to attack as
long as the identity of the supernodes is known. If the identity of the
supernodes is not known, then how will they be notified about new data?
Note that broadcasting is probably not an acceptable solution.
Kevin Winter
As far as i can tell, GNUnet _does_ provide end-to-end encryption. On
their FAQ, they mention deniablity, which indicates that any
intermediary node can deny knowledge of what packets they pass due to
the encrypted nature of communications (end-to-end). The signing to
to guarantee authenticity, as theoretically a misbehaving node can
acquire the public key of a targetted node, and transmit a message to
them claiming to be a SU or such.
Kevin Winter
I quite agree. We wrote both methods into the draft because
journeyman like the single server idea, whereas i liked using the
GNUnet "DHT" implementation (not sure if it quite qualifies).
Basically, GNUnet allows one to index their stored files
(spams/scripts). The entire network is searchable, similarly to
gnutella, where search results are returned as they are found.
Multiple source downloads are also allowed.
My idea is to use GNUnet as a base, fork the code, and extend it to
provide the features we need, thereby cutting down on developement
time.
I'll be honest, i liked what i have seen of audrey; however, it is as
of yet uncompleted, and there is a marked lack of activity. Thats why
journeyman and myself talked about using gnunet to speed developement
of a client.
Journeyman
because we didn't know if you would ever finish your paper as you have
been inactive for some time, also using gnunet keeps us from having to
reinvent the wheel, it also has alot of great features we can use.
Gnunet does provide end-to-end encryption, however I think you mean the
message itself needs to be encrypted, and I didn't think of how Spamer
A would let spams from spammer B and C pass and only block his own
therefor making it harder to detect. with this in mind we will indeed
encrypt all spam reports.
and please if you want to finish your paper that would be great I was
just hoping to jump start the project a bit with this, or keep it from
dieing atleast
nano
what I started.