p2psp team mailing list archive

[Ilshat Shakirov <im.shakirov@xxxxxxxxx>]

Hello!,


> 1) Why a different socket is needed for poisoned chunks?

Because in the other case, I have to override long method
*process_next_message.
*I thought that the solution with replacing socket is more clear.

2)Malicious peer relay chunks received from splitter. If the sppliter does
> not send chunks to a malicious peer, What chunk is relayed?
>
In current impl no chunk is relayed if splitter doesn't send chunks to
malicious peer. I will fix it later (in this week).

3) crc32 is not suitable as cryptographic hash function. See
> http://en.wikipedia.org/wiki/Cryptographic_hash_function.
>
I will use sha256 instead. Is it ok?

4) I do not see the problem with 255. Trusted peer just send information to
> the sppliter about the chunks received and who send them.
>
I think that it is the problem, because trusted peer can never send the
chunks from malicious peer (if malicious peer will be lucky and its chunks
won't be 255th in trusted peer).

ps: about 2: is there need to implement this functionality; because if peer
will not receive new chunks from splitter, he won't know the chunk numbers,
and he cannot fake the chunk messages (since it doesn't know chunk numbers).

Thanks!


2015-06-01 12:55 GMT+05:00 L.G.Casado <leo@xxxxxx>:

>  Hello Ilshat,
>
> Please can you answer the following questions:
>
> 1) Why a different socket is needed for poisoned chunks?
> 2)Malicious peer relay chunks received from splitter. If the sppliter does
> not send chunks to a malicious peer, What chunk is relayed?
> 3) crc32 is not suitable as cryptographic hash function. See
> http://en.wikipedia.org/wiki/Cryptographic_hash_function.
> 4) I do not see the problem with 255. Trusted peer just send information
> to the sppliter about the chunks received and who send them.
>
> Best,
>
> Leo
>
>
>
> El lun, 01-06-2015 a las 00:51 +0500, Ilshat Shakirov escribió:
>
> Hello!,
>
>
>  Here is the post about results of the first week:
> http://shakirov-dev.blogspot.ru/2015/05/the-first-week.html
>
>
>  Im currently in progress in preparing the plan of testing, I will
> suggest the first version of it by the end of the second week.
>
>
>  Thanks!
>
>
>  2015-05-25 16:40 GMT+05:00 Ilshat Shakirov <im.shakirov@xxxxxxxxx>:
>
>  Hello!,
>
>
>   I have just implemented and tested malicous peer, which simply sends
> zero chunk to the rest of team. Here it is.
> <https://github.com/P2PSP/p2psp/compare/master...ishakirov:master>
>
>  Yes, that's the first step, sending poisoned chunk to the rest. But
> malicious peer is supposed to be smart, trying to avoid policies or
> colluding with others...
> In any case, STrPe-DS is more interesting in a real scenario.
>
>   Ok, so I will try to implement STrPe as soon as possible, and start to
> implement STrPe-DS  with smart malicious peer. I think I should implement
> bad-mouth and selective attacks, is it enough?
>
>  I use Linux.
>
>   The problem was solved on its own, so I can test everything in local
> team. Thanks =)
>
>
>
>
>   2015-05-25 16:28 GMT+05:00 L.G.Casado <leo@xxxxxx>:
>
>   Dear all,
> El lun, 25-05-2015 a las 14:13 +0500, Ilshat Shakirov escribió:
>
>  Malicious peers will be smart and they can perform different types of
> attacks.
> Keep in main that the goal  is to check the efficiency of  STrPe and
> STrPe-DS against those type of attacks.
>
> The first step is to implement STrPe. I think that the malicious peer
> which will just send poisoned chunk (000..00) is enough for evaluating
> STrPe. (am I right?)
>
> Yes, that's the first step, sending poisoned chunk to the rest. But
> malicious peer is supposed to be smart, trying to avoid policies or
> colluding with others...
> In any case, STrPe-DS is more interesting in a real scenario.
>
>
>  We have to agree about what experiments (number of malicious peers, type
> of attacks, etc) are needed to check the results and your code.
>
> It's ok. I will prepare plan asap.
>
> Thanks.
>
>  It is rare the system go down for 5-10 sec. What is the environment you
> are checking it?
>
> MacOS (yosemite); I run splitter, monitor and peer. When system is going
> to down, the vlc out the error messages like *can't decode timestamp.
> But it occurs from time to time, ie today morning all was ok =) And I just
> check it again, all was ok.
>
> I use Linux.
>
> Best,
>
> Leo
>
>
>
>
>
>