Hello!, as far as I understood, Monitor and Trusted peers are the different names > for the same type of peer. >
No, this is 2 different peers in the team. Is it right? We need to perform more realistic scenarios. For instance a group of people > sharing a video. > Ok. Let fix the number of well intended peers to 20. > 1.1 and 1.2 seems to be solved. > 1.3 also. > What about 1.2-1.3 together. As malicious peer, once discovered I guess > who is the Trusted peer I will sent good chunks in new off-on connection. > So I can perform a selective attack. > Does malicious 1-2-1.3 peer persists? Give an advice of how to solve this > type of attack (The code for the solution for your advice is not part of > GSoC) > 1.4 (Has no sense in STrPe) because Spliter only hear from Trusted peer. > 1.5. DoS was not selected as one of the attacks in GSoC > 1.6. Collaborative Attack: One of the malicious peers can inform the > others about a possible Trusted peer. Ok, I will edit the document to suit this conditions. So, Just use a set of 20 well intended peers and add a different number of > malicious peers (1 to 40) and different type of (basic) attacks in order > to know how many malicious peers and of what type of attacks the fix (20 > well intended peers and one Trusted peer) system can support. > System performance can be measured, for instance, in how many good chunks > have a good peer received out of all. > Ok; Is there any option run peer without running a player? I'm going to run all peers in one local machine, is it right? --- After seeing your exps: the message you're signing is 13312 bytes long, > i.e. 13 KB. However our chunks are 1KB long. Can you repeat the exps with > 1KB message? I guess the new message could be "a"*1024 right? (check with > the len() function). The length of the message affects the time taken by > the hash function. The signature itself should take the same time, since > we're doing it to a 256 bits input. > To be honest, I choosed the message randomly. =) Here is result for 1KB message: > MacBookPro-Ilya-Shakirov:crypto-test i.shakirov$ ./test-pycrypto.py > key.sign x10 times: 0.00248003005981s > key.verify x10 times: 0.0025269985199s > MacBookPro-Ilya-Shakirov:crypto-test i.shakirov$ ./test-pycrypto.py > key.sign x100 times: 0.0277769565582s > key.verify x100 times: 0.0267798900604s > MacBookPro-Ilya-Shakirov:crypto-test i.shakirov$ ./test-pycrypto.py > key.sign x1000 times: 0.289718151093s > key.verify x1000 times: 0.268572807312s > Also: when you say, for example, "key.sign x10 times: 0.00385499000549s" > then it means that 0.00385499000549s is the time taken in doing 10 > signatures, right? Then the time for a single signature would be > 0.00385499000549s/10 = 0.0003s That seems too small... What setup are you > using? I've run your test in my own machine and I get results one order of > magnitude higer. However I'm in an out-of-the-box Windows 8.1 (I just > bought a new machine, didn't have time yet to install Linux :D) and it > looks like the Python runtime is sooooo slow here. I'm using Python 2.7 by > the way. > My setup is i7 2.9 GHz, 8Gb RAM (OSX); python 2.7.6; btw, I couldn't run the whole p2psp-team in windows environment =) Thanks! 2015-06-23 14:50 GMT+05:00 Juan Álvaro Muñoz Naranjo <[email protected] >: > Thanks for the info Ilshat! > > After seeing your exps: the message you're signing is 13312 bytes long, > i.e. 13 KB. However our chunks are 1KB long. Can you repeat the exps with > 1KB message? I guess the new message could be "a"*1024 right? (check with > the len() function). The length of the message affects the time taken by > the hash function. The signature itself should take the same time, since > we're doing it to a 256 bits input. > > Also: when you say, for example, "key.sign x10 times: 0.00385499000549s" > then it means that 0.00385499000549s is the time taken in doing 10 > signatures, right? Then the time for a single signature would be > 0.00385499000549s/10 = 0.0003s That seems too small... What setup are you > using? I've run your test in my own machine and I get results one order of > magnitude higer. However I'm in an out-of-the-box Windows 8.1 (I just > bought a new machine, didn't have time yet to install Linux :D) and it > looks like the Python runtime is sooooo slow here. I'm using Python 2.7 by > the way. > http://stackoverflow.com/questions/1842798/python-performance-on-windows > > http://stackoverflow.com/questions/10150881/why-is-python-so-much-slower-on-windows > > Here are my results: > > Python 2.7.7 (default, Jun 1 2014, 14:21:57) [MSC v.1500 64 bit (AMD64)] > on win32 > Type "copyright", "credits" or "license()" for more information. > >>> ================================ RESTART > ================================ > >>> > key.sign x10 times: 0.0210001468658s > key.verify x10 times: 0.0209999084473s > >>> ================================ RESTART > ================================ > >>> > key.sign x100 times: 0.246000051498s > key.verify x100 times: 0.230000019073s > >>> ================================ RESTART > ================================ > >>> > key.sign x1000 times: 2.27099990845s > key.verify x1000 times: 2.10100007057s > >>> > > Juan > > 2015-06-23 9:11 GMT+02:00 Ilshat Shakirov <[email protected]>: > >> Hello, >> >> here is exact results for pycrypto: >> >> key.sign x10 times: 0.00385499000549s >>> key.verify x10 times: 0.00309109687805s >>> >>> key.sign x100 times: 0.0352149009705s >>> key.verify x100 times: 0.0317900180817s >>> >>> key.sign x1000 times: 0.332525968552s >>> key.verify x1000 times: 0.326780080795s >> >> >> Also, I've updated post. >> >> Thanks! >> >> 2015-06-23 0:34 GMT+05:00 Juan Álvaro Muñoz Naranjo < >> [email protected]>: >> >>> Hi Ilshat, >>> >>> great job during last week. >>> >>> Regarding the signature benchmarks it is clear that DSA is the >>> preferable option. However, the plot does not allow to appreciate the exact >>> result in seconds for DSA. Can you just post the exact numbers? We need to >>> check if DSA's is enough for signing and verifying a stream of chunks. >>> >>> Best, >>> >>> Juan >>> >>> >>> 2015-06-22 20:58 GMT+02:00 Vicente Gonzalez < >>> [email protected]>: >>> >>>> Have you check that the VLC is serving the video well? (Please, connect >>>> to http://localhost:8080 with Firefox or with VLC when you detect that >>>> the problem happens). >>>> >>>> On Mon, Jun 22, 2015 at 8:54 PM Ilshat Shakirov <[email protected]> >>>> wrote: >>>> >>>>> Hi, >>>>> >>>>> Not really, I just open many tabs in mac terminal (instead of using >>>>> xterm); >>>>> Order of commands is the same. >>>>> >>>>> 2015-06-23 0:50 GMT+06:00 Vicente Gonzalez < >>>>> [email protected]>: >>>>> >>>>>> Hi Ilshat, >>>>>> >>>>>> are you using the commands I can see in your blog? >>>>>> >>>>>> Regards, >>>>>> Vi. >>>>>> >>>>>> On Sun, Jun 21, 2015 at 9:59 PM Ilshat Shakirov < >>>>>> [email protected]> wrote: >>>>>> >>>>>>> Hi all! >>>>>>> >>>>>>> Here is new blogpost: >>>>>>> http://shakirov-dev.blogspot.ru/2015/06/the-third-week.html >>>>>>> >>>>>>> Also, I want you to test my code please. There is strange errors >>>>>>> sometimes. After monitor is connected, it doesnt receive new chunks from >>>>>>> splitter. And after the trusted peer is connected to team, monitor >>>>>>> exclude >>>>>>> it from team for 129 losses. It occurs sometimes, and I can't understand >>>>>>> why it's happening. >>>>>>> >>>>>>> Thanks! >>>>>>> >>>>>>> 2015-06-20 5:05 GMT+05:00 Juan Álvaro Muñoz Naranjo < >>>>>>> [email protected]>: >>>>>>> >>>>>>>> FYI: >>>>>>>> >>>>>>>> https://torrentfreak.com/popular-torrents-being-sabotaged-by-ipv6-peer-flood-150619/ >>>>>>>> >>>>>>>> >>>>>>>> Le 18 juin 2015 19:41:12 CEST, Ilshat Shakirov < >>>>>>>> [email protected]> a écrit : >>>>>>>>> >>>>>>>>> Hi all! >>>>>>>>> >>>>>>>>> Sorry for the delay in the response. >>>>>>>>> >>>>>>>>> -On replacing CRC32 for SHA-256. ... >>>>>>>>>> >>>>>>>>> Ok, thanks for the explanation. >>>>>>>>> >>>>>>>>> Overriding sendto() function ... >>>>>>>>>> >>>>>>>>> Thanks =) >>>>>>>>> >>>>>>>>> -Packet verification frequency (the 255 problem). >>>>>>>>>> >>>>>>>>> Ok, I will do it as you described. >>>>>>>>> >>>>>>>>> -Malicious peers sending packets even after expelled. ... >>>>>>>>>> >>>>>>>>> I will return to this task after implementing the first steps in >>>>>>>>> STrPe-DS. >>>>>>>>> >>>>>>>>> Regarding testing crypto-libs: >>>>>>>>> I have performed that tests, here is results: >>>>>>>>> >>>>>>>>>> MacBookPro-Ilya-Shakirov:crypto-test i.shakirov$ ./test-ecdsa.py >>>>>>>>>> key.sign x100 times: 2.76373291016s >>>>>>>>>> key.verify x100 times: 5.61430811882s >>>>>>>>>> MacBookPro-Ilya-Shakirov:crypto-test i.shakirov$ >>>>>>>>>> ./test-pycrypto.py >>>>>>>>>> key.sign x100 times: 0.0404751300812s >>>>>>>>>> key.verify x100 times: 0.038027048111s >>>>>>>>>> >>>>>>>>> My laptop config is i7 2.9GHz; 8Gb RAM; >>>>>>>>> Source of this synth-tests can be found here: >>>>>>>>> https://github.com/ishakirov/p2psp/commit/d833589ffc5a9a923123c56a74bc0bba2a79c97a >>>>>>>>> >>>>>>>>> I think that pycrypto lib is suitable for our needs in speed. So >>>>>>>>> Im planning to use it in STrPe-DS implementation. >>>>>>>>> >>>>>>>>> PS. Sorry for 3rd week blogpost, but I think there is too small >>>>>>>>> results to write blogpost. But 4th week blogspot will be. =) >>>>>>>>> >>>>>>>>> Thanks! >>>>>>>>> >>>>>>>>> >>>>>>>>> 2015-06-15 11:19 GMT+05:00 Vicente Gonzalez < >>>>>>>>> [email protected]>: >>>>>>>>> >>>>>>>>>> Hi everybody! >>>>>>>>>> >>>>>>>>>> Just a little remark to this long but insightful message (thanks >>>>>>>>>> Juan Alvaro). >>>>>>>>>> >>>>>>>>>> First, yes, using DS should be the definitive solution, but, >>>>>>>>>> regarding this: >>>>>>>>>> >>>>>>>>>> On Sun, Jun 14, 2015 at 9:04 PM Juan Álvaro Muñoz Naranjo < >>>>>>>>>> [email protected]> wrote: >>>>>>>>>> >>>>>>>>>> all peers behind the same public IP (NAT scenario) will be >>>>>>>>>>> banned if one of them is malicious >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> It the EMS set of rules is implemented, more than one peer can be >>>>>>>>>> in the same private network and all are different for the splitter. >>>>>>>>>> >>>>>>>>>> Cheers, >>>>>>>>>> Vi. >>>>>>>>>> -- >>>>>>>>>> -- >>>>>>>>>> Vicente González Ruiz >>>>>>>>>> Depto de Informática >>>>>>>>>> Escuela Técnica Superior de Ingeniería >>>>>>>>>> Universidad de Almería >>>>>>>>>> >>>>>>>>>> Carretera Sacramento S/N >>>>>>>>>> 04120, La Cañada de San Urbano >>>>>>>>>> Almería, España >>>>>>>>>> >>>>>>>>>> e-mail: [email protected] >>>>>>>>>> http://www.ual.es/~vruiz >>>>>>>>>> tel: +34 950 015711 >>>>>>>>>> fax: +34 950 015486 >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> Mailing list: https://launchpad.net/~p2psp >>>>>>>>>> Post to : [email protected] >>>>>>>>>> Unsubscribe : https://launchpad.net/~p2psp >>>>>>>>>> More help : https://help.launchpad.net/ListHelp >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> -- >>>>>>>> Enviado desde mi teléfono con K-9 Mail. >>>>>>>> >>>>>>> >>>>>>> -- >>>>>> -- >>>>>> Vicente González Ruiz >>>>>> Depto de Informática >>>>>> Escuela Técnica Superior de Ingeniería >>>>>> Universidad de Almería >>>>>> >>>>>> Carretera Sacramento S/N >>>>>> 04120, La Cañada de San Urbano >>>>>> Almería, España >>>>>> >>>>>> e-mail: [email protected] >>>>>> http://www.ual.es/~vruiz >>>>>> tel: +34 950 015711 >>>>>> fax: +34 950 015486 >>>>>> >>>>> >>>>> -- >>>> -- >>>> Vicente González Ruiz >>>> Depto de Informática >>>> Escuela Técnica Superior de Ingeniería >>>> Universidad de Almería >>>> >>>> Carretera Sacramento S/N >>>> 04120, La Cañada de San Urbano >>>> Almería, España >>>> >>>> e-mail: [email protected] >>>> http://www.ual.es/~vruiz >>>> tel: +34 950 015711 >>>> fax: +34 950 015486 >>>> >>> >>> >> >
-- Mailing list: https://launchpad.net/~p2psp Post to : [email protected] Unsubscribe : https://launchpad.net/~p2psp More help : https://help.launchpad.net/ListHelp
