Hello!, Here are some final results of testing STrPe&STrPe-DS mechanisms.
STrPe-DS | Persistent attack: https://docs.google.com/spreadsheets/d/1iSNQwanXT10XravpkfPz706ASdeIv3NvUOF0QqMU3rg/edit#gid=0 STrPe-DS | On-off attack: https://docs.google.com/spreadsheets/d/1AcrhbcFvd_iRISeDa26ObRiApPHpV4-BqPoRipiKRcc/edit#gid=0 Network usage (by rounds): https://docs.google.com/spreadsheets/d/1LhypThplzYVpiNWfnuLH73H-ZagznKO2BYzjCk1dXdE/edit?usp=sharing The really interesting result is network usage sheet. The both mechanisms have very low overhead (no more than 10%, service messages, like list of bad peers, chunk_check message and so on) costs very low traffic. Tests was performed in the team with 10 peers (9 well-intended peers and one trusted peer). About STrPe-DS: Also, in case of persistent attack and on-off attack mal. peers was discovered very fast. Also, number of trusted peers in the team doesnt affect on this speed (at all). So, in on-off attack I performed tests only with 1 TP. Because of this speed, mal. peers don't have time to do much harmful effect on the team, it can be seen on buffer_filling graphs. Currently, Im preparing last blogpost. Thanks! 2015-08-18 18:36 GMT+06:00 Ilshat Shakirov <[email protected]>: > Hello!, > > >> They are nice results. >> > > Thanks! > > >> What 40% on-off attack means? >> > > In 40% of cases peer sends poisoned chunk instead of correct chunk. > > > 2015-08-18 17:34 GMT+05:00 L.G.Casado <[email protected]>: > >> Dear Ilshat, >> >> They are nice results. >> What 40% on-off attack means? >> >> >> Best, >> >> Leo >> >> El mar, 18-08-2015 a las 17:24 +0500, Ilshat Shakirov escribió: >> >> Hello!, >> >> Here is small status update. >> I've implemented new types of attack for malicious peers: >> -persistent attack >> -on-off attack >> -selective attack >> -bad-mouth attacj (for strpe-ds only) >> >> Also, I've added new option --checkall for STrPe trusted peers. If this >> option is enablde, then TP sends every received chunk to splitter to check. >> >> Here is some tests I performed for STrPe mechanism: >> Persistent attack (with checkall option) : >> https://docs.google.com/spreadsheets/d/1iNva1mvO9NETj8fJ9oZpy1VhAUYxJi4K7gUojqzSEqI/edit >> On-off attack (40%) : >> https://docs.google.com/spreadsheets/d/1-sLkrjdNQHx-jXxWeVYz4pmnd6qgC1D3MuVnbhQ4lYE/edit?usp=sharing >> >> For each configuration Ive performed 5 experiments, on last tab the >> result table is presented. >> >> I've made next observations (for STrPe): >> - there is need to increase splitter's buffer, since it have to check >> chunks which can be deleted from its buffer. I've performed tests with >> --buffer_size 1024 (256 by default). I think that buffer should smth like 4 >> * team_size. >> - with check all option number of TP doesnt affect speed of expulsion >> mal. peers (in case of persistent attack). Every mal. peer is excluding for >> 1 splitter round in average. >> - in on-off attack number of TP affects on speed of excluding peers. So, >> more TPs - more chances to send posioned chunks to TP. >> - there is very small affect on buffer correctness for all the team. >> Average for the team is between 0.95 and 1. >> >> Also, here is my testing plan : >> https://docs.google.com/document/d/13oSUgkRrmUh8nM3mMe5FEmwBlSfrxs0NXkei0JVubBo/edit?usp=sharing >> >> Currently, Im performing tests for STrPe-DS mechanism (according to my >> test plan). >> >> Thanks. >> >> 2015-08-14 2:03 GMT+05:00 Ilshat Shakirov <[email protected]>: >> >> Hello!, >> >> Here is two raw data sets with result data from experiments with STrPe >> and STrPe-DS: >> >> STrPe: >> https://docs.google.com/spreadsheets/d/13xzEwQKbB58p0K8VyQjvez2L-QABP_ouelbqmWMSE7w/edit#gid=1026220953 >> STrPe-DS: >> https://docs.google.com/spreadsheets/d/1YZnLaWrjAJRgXZ2LQrHhgewOnzL1Fm073ix6dULmwpc/edit#gid=1531244678 >> >> As you can see in STrPe number of TP affects on speed of expulsion mal. >> peers. It happens because TP selects next chunk to check randomly from its >> stream of chunks. Resp. if we have more TP then it will take less number of >> rounds to expel all TP. >> You can check it in code here: >> https://github.com/P2PSP/p2psp/blob/cis/src/trusted_peer.py#L55 >> >> Also, you can see that in STrPe-DS if we have more mal. peers, we have >> more rounds to expel all mal. peers. It happens because including new mal. >> peers take 0.5 - 1 round, and resp. we have more rounds to include all mal. >> peers to the team. In the simple persistent attack mal. peers excluding >> almost at the same time they sended poisoned chunk to TP. >> >> Why a TP does not check every chunk? >> In a persistent attack, peers will be detected directly. >> >> >> Because it can reduce the performance of TP and the system (I think) >> >> Again, for persisten attack this is true, but not for the more >> sophisticated ones. >> >> What kinds of attack should I perform? >> >> Also, I think I know how to compromise Third Trusted Party (and resp. >> perform selective attack) for only log(n) time. >> Attacker should perform attack on the half of the team. If mal. peer was >> excluded, then in given half exists TP. Then this half divide to new 2 >> halfs and so on. So, we can find all the TPs in O(log2(n)) time. >> >> Thanks! >> >> >> 2015-08-12 15:43 GMT+05:00 L.G.Casado <[email protected]>: >> >> Hello, >> >> >> El mié, 12-08-2015 a las 15:27 +0500, Ilshat Shakirov escribió: >> >> Hello, >> >> N-1, is set because there is one Trusted peer, does it? >> >> >> Yes, because trusted peer doesnt check itself. >> >> >> How is set X, random check yes/no? >> >> I think yes. In the first impl of STrPe trusted peers checked every 255 >> received chunk. >> >> >> Why a TP does not check every chunk? >> In a persistent attack, peers will be detected directly. >> >> The random check could be seen as malicious peer performing a kind of >> selective attack. >> >> About current progress: >> I've found a small bug in the initialization of big teams (i.e. 100 >> peers) with enabled STrPe-DS. In 2-3% of cases peer hangs up and do nothing. >> >> Then, they should be expeled soon. >> >> Also, Ive prepared a raw data from STrPe experiments (Ive performed >> experiments with 100 peers, 1-2-4-8 trusted, and 10-25 malicious). And >> since trusted peers in STrPe checks chunks randomly from all the peers in >> the team, it can take long time to expel all the malicious peers. It >> happens because TP selects chunk to check from all stream, although it >> should select chunks from each peer. >> >> >> I think to check randomly has no sense if trusted peer is in system >> without resources limitations, which should be the case. >> >> If we implement this, then Juan will be right and number of TPs in the >> team won't have impact on mal. peer expulsion. Now, if we have more TP, we >> have more chances, that TP will check chunk from mal. peers and will >> exclude it. >> >> Yes, checking them all, just on TP is enough for persistent attack, but >> it is not the case for other attacks. >> >> Also, STrPe-DS don't have such problem, because I've implemented next >> logic:Every S seconds splitter selects new peer from all the team and TP >> from trusted peers and do 2 requests to gather complains from the team. >> >> So, mal. peers will be excluded almost in the same time they ve sended >> poisoned chunks to TP. >> >> Again, for persisten attack this is true, but not for the more >> sophisticated ones. >> >> Thanks! >> >> Best, >> >> Leo >> >> 2015-08-12 15:08 GMT+05:00 L.G.Casado <[email protected]>: >> >> Dear Ilshat, >> >> El mié, 12-08-2015 a las 12:04 +0200, L.G.Casado escribió: >> >> BC = 1 - M / (N - 1 + 1) = 1 - M / N, >> >> >> Sorry, the formula was fine: >> >> (N-M)/N= 1-M/N >> >> Please, answer the other questions. >> >> Thanks, >> >> Leo >> >> >> >> >> >> >> >
-- Mailing list: https://launchpad.net/~p2psp Post to : [email protected] Unsubscribe : https://launchpad.net/~p2psp More help : https://help.launchpad.net/ListHelp
