p2psp team mailing list archive

[Ilshat Shakirov <im.shakirov@xxxxxxxxx>]

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 <juanalvaro83@xxxxxxxxx
>:

> 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 <im.shakirov@xxxxxxxxx>:
>
>> 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 <
>> juanalvaro83@xxxxxxxxx>:
>>
>>> 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 <
>>> vicente.gonzalez.ruiz@xxxxxxxxx>:
>>>
>>>> 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 <im.shakirov@xxxxxxxxx>
>>>> 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 <
>>>>> vicente.gonzalez.ruiz@xxxxxxxxx>:
>>>>>
>>>>>> 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 <
>>>>>> im.shakirov@xxxxxxxxx> 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 <
>>>>>>> juanalvaro83@xxxxxxxxx>:
>>>>>>>
>>>>>>>> FYI:
>>>>>>>>
>>>>>>>> https://torrentfreak.com/popular-torrents-being-sabotaged-by-ipv6-peer-flood-150619/
>>>>>>>>
>>>>>>>>
>>>>>>>> Le 18 juin 2015 19:41:12 CEST, Ilshat Shakirov <
>>>>>>>> im.shakirov@xxxxxxxxx> 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 <
>>>>>>>>> vicente.gonzalez.ruiz@xxxxxxxxx>:
>>>>>>>>>
>>>>>>>>>> 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 <
>>>>>>>>>> juanalvaro83@xxxxxxxxx> 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: vruiz@xxxxxx
>>>>>>>>>> http://www.ual.es/~vruiz
>>>>>>>>>> tel: +34 950 015711
>>>>>>>>>> fax: +34 950 015486
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Mailing list: https://launchpad.net/~p2psp
>>>>>>>>>> Post to     : p2psp@xxxxxxxxxxxxxxxxxxx
>>>>>>>>>> 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: vruiz@xxxxxx
>>>>>> 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: vruiz@xxxxxx
>>>> http://www.ual.es/~vruiz
>>>> tel: +34 950 015711
>>>> fax: +34 950 015486
>>>>
>>>
>>>
>>
>