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:
1. *Malicious peer* : Is there need to implement sending chunks after splitter removed this peer from its (splitter) peer list? 2. *STrPe *: Is there need to implement expel message for peers? (message about that peer A is malicious) 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 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. Thanks! 2015-06-01 13:22 GMT+05:00 Ilshat Shakirov <[email protected]>: > 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 <[email protected]>: > >> 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 <[email protected]>: >> >> 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 <[email protected]>: >> >> 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 >> >> >> >> >> >> >
-- Mailing list: https://launchpad.net/~p2psp Post to : [email protected] Unsubscribe : https://launchpad.net/~p2psp More help : https://help.launchpad.net/ListHelp
