Dear Ilshat, Yes, more than one trusted peer seems not to be interesting for current coded attacks. Nice results. Best, Leo El lun, 24-08-2015 a las 02:57 +0600, Ilshat Shakirov escribió: > 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/1Acr > hbcFvd_iRISeDa26ObRiApPHpV4-BqPoRipiKRcc/edit#gid=0 > Network usage (by rounds): https://docs.google.com/spreadsheets/d/1Lh > ypThplzYVpiNWfnuLH73H-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/documen > > > > t/d/13oSUgkRrmUh8nM3mMe5FEmwBlSfrxs0NXkei0JVubBo/edit?usp=shari > > > > ng > > > > > > > > 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/13xzEwQKbB58p0K > > > > > 8VyQjvez2L-QABP_ouelbqmWMSE7w/edit#gid=1026220953 > > > > > STrPe-DS: https://docs.google.com/spreadsheets/d/1YZnLaWrjAJR > > > > > gXZ2LQrHhgewOnzL1Fm073ix6dULmwpc/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
