p2psp team mailing list archive

[Juan Álvaro Muñoz Naranjo <juanalvaro83@xxxxxxxxx>]

Hi Ilya,

great job so far, I just merged your work during weeks 1 and 2. I can't
wait to read the 3rd week blog post! ;)

Below are some thoughts on your dicussion with Leo so far. It's a bit long
and the most interesting stuff is at the end, apologies!

-On replacing CRC32 for SHA-256. That's a good thing to do. The main
problem with CRC32 (and not resilient enough codes or hash functions in
general) is that it's easy enough to find a collision. Consider packet M
and its hash H(M). Finding a collision for M means finding another packet
M' such that H(M') = H(M). If a malicious peer can easily find collisions
this means he can forge a packet M' that will fool the Splitter because
(again) H(M') = H(M), so the Splitter would not detect that the packet is
false. That's why it is so importat to use a cryptographically secure hash
function. Briefly speaking, the longer the output of the hash function, the
more secure it should be against collisions (there are other factors of
course). So CRC32 (32 bits output), MD5 (128 bits output) are out of the
question, and even SHA-1 is not recommended any more. So you did a good
thing by choosing SHA-256 ;) The drawback, of course, is the increase in
message length which will affect the use of bandwidth.

-Overriding sendto() function in the new class MaliciousSocket: OK with
that, I see that you preferred to override a low level method since it'd be
faster and cleaner.

-Packet verification frequency (the 255 problem). Ok, this is a big one:
the current static solution is not enough. The Trusted Peer needs to verify
packets on a random basis. Let me explain why.

If malicious peers know that packet verification is done every 255 packets
then they can easily calculate which packets are verified (254, 509, 764,
1019, 1274, ...), which makes our defense mechanism useless. The malicious
peer can even test this by forging those exacts packets and seeing if he's
consequently expelled! Even if the malicious peer doesn't know the exact
frequency (say that the TP uses a value different than 255), then he can
try to be expelled two consecutive times and calculate the difference.

So packet sampling must be absolutely random. I suggest the following:
next_sampled_index = previous_sampled_index + random(0, team_size)

Now, let's increase the frequency so we verify more than one packet per
team iteration:
next_sampled_index = previous_sampled_index + random(0, team_size /
sampling_effort)

where sampling_effort = [1, team_size]. Of course, sampling frequently
combined with having a long hash output (256 bits) will make us use a lot
of bandwidth just in sending the hashes to the splitter.

-Malicious peers sending packets even after expelled. Just some ideas on
this, I have not solved it.

When a malicious peer sends a packet after being expelled, then there exist
two packets with the same index number: the "legal" one and the "forged"
one. For example, for packet P100 we would have the legal one, P100' and
the malicious one, P100''. What happens next? Both P100' and P100'' reach
the Trusted Peer. Even if the TP didn't intend to verify P100, it will be
inmediately obvious that there is a problem there, since it received the
same packet twice and both versions were different. Then it should forward
both hashes H(P100') and H(P100'') to the Splitter, which in tourn would be
able to decide which packet is the forged one. But after that: what can the
Splitter do? The malicious peer is already banned from the team but will
keep on sending junk messages! I guess maintaining a blacklist of banned
IPs is the most simple solution, though I can see two problems there: (1)
all peers behind the same public IP (NAT scenario) will be banned if one of
them is malicious, and (2) a clever malicious peer might forge the IP
address of the packet and change to a new one at a very high frequency,
thus deeming useless the blacklist approach (even worse, peers would end up
with ever-increasing huge lists).

This problem makes me now think that the STrPe-DS is a safer approach: the
digital signature solves all this problems by definition.

-For STrPe-DS: we need a signature algorithm that is efficiently
implemented in Python so we can generate signatures at a decent speed.
Could you test the average time for signing and verifying by using the
following algorithms?
--DSA: https://www.dlitz.net/software/pycrypto/api/2.6/
--ECDSA: https://github.com/warner/python-ecdsa (there are some time
estimations in the page. Those times are terrifying slow, but let's
double-check just to be sure ok?)

Sadly anything we run in python will be super slow, and this concerns me.
In the worst case there is a Python wrapper for OpenSSL (which is in turn
implemented in C) which might be faster:
http://bazaar.launchpad.net/~exarkun/pyopenssl/master/view/head:/OpenSSL/crypto.py
(we can use DSA there).

-If STrPe-DS is terribly slow when signing/verifying: I've already thought
of a different approach based on symmetric authentication (much faster than
public-key authentication). But it is far more complex and it's too early
for that yet. Let's go step by step.

We also need to decide what experiments are we going to run for the STrPe
approach. Let Leo and me think a bit more about that.

Cheers, sorry for the long email :D


Juan

2015-06-09 13:05 GMT+02:00 L.G.Casado <leo@xxxxxx>:

>  Hello Ilshat,
>
> I answer between lines.
>
> El mar, 09-06-2015 a las 00:37 +0500, Ilshat Shakirov escribió:
>
> Hello!,
>
> Here is report for the second week:
> http://shakirov-dev.blogspot.ru/2015/06/the-second-week.html
>
>  It's quite small, but I want to end the STrPe part of project by this
> week (or may be by the next week), so I have some questions:
>
> Fine!.
>
>  1. *Malicious peer* : Is there need to implement sending chunks after
> splitter removed this peer from its (splitter) peer list?
>
> It has no sense because Spliter will attend only to peers on list and
> request to be included in the team.
> We did not think in a DoS by repeating a lot of inclusion requests.
>
> Other peers will only attend to peers in their lists.
>
>
>  2. *STrPe *: Is there need to implement expel message for peers?
> (message about that peer A is malicious)
>
> In this version there is not such functionality. The aim is to make a very
> simple protocol by reduce computation and communication at peers.
>
>  3. *Testing plan* : How it should looks like? I am preparing plan with
> different kinds of attacks, smth like this:
>
>   *STrPe:*
>
>   *  On-off attack:*
>
>   *    Confguration of team: 1 monitor, 1 trusted, 1 malicious which is
> reconnecting to splitter after detection*
>
>   *    Expected: Malicious peer is detected every time it is reconnecting*
>
>   *    Actual: ______*
>
>
>   *  Bad-mouth attack:*
> *....*
>
>  The goal is to have the Spliter, Trusted peer and malicious
> functionalities in order to perform several configurations and get
> statistics about the efficiency of the expelling system.
> For instance, play with different ratios of trusted and malicious peers
> and different types of attacks.
>
>
>  The main question is about section 'Expected' : What params I should
> mention in this section? Description '*Malicious peer is detected every
> time it is reconnecting' *looks a little bit informal.
>
> You know attackers are smart, so you have to think as them. For instance,
> a selective attack until detected can avoid to poison chunk for the now
> known trusted peer. If there is just one, malicious can survive, or not?
>
>  Thanks!
>
>
> Thanks to you.
>
> Best,
>
> Leo
>