Re: [viff-devel] VIFF needs at least 3 players always?
Citat af Kyung-Wook Hwang kwhw...@ee.columbia.edu: Hello, This is Kyung Hwang from Columbia University again. I have another question. Does Viff always need at least 3 participants? It seems to me it does. That depends on the runtime you use. If you are using the default passive security runtime, this is based on Shamir secret-sharing. Therefore there must be at least 3 parties, and the threshold will always be n/2. There is in fact also a two-party runtime based on the Paillier cryptosystem. You can check it out if you want, it's in paillier.py. But basically you have to select a runtime that gives you what you want. If you want 2-party MPC, you can't use the Shamir sharing based runtime. I modified beginner.py for two players because that file was simplest to modify, but when I ran the two players, I got the following errors: kwhw...@kwhwang-sim1:~/viff-1.0/apps$ python beginner2.py player-2.ini 20 --no-ssl Seeding random generator with random seed 3781 /home/kwhwang/opt/lib/python/viff/prss.py:43: DeprecationWarning: the sha module is deprecated; use the hashlib module instead import sha I am player 2 and will input 20 Not using SSL Listening on port 9002 Starting reactor ### Program started Error: [Failure instance: Traceback: type 'exceptions.KeyError': 3 /home/kwhwang/opt/lib/python/viff/runtime.py:317:stringReceived /home/kwhwang/opt/lib/python/viff/runtime.py:456:identify_peer /usr/lib/python2.6/dist-packages/twisted/internet/defer.py:280:callback /usr/lib/python2.6/dist-packages/twisted/internet/defer.py:354:_startRunCallbacks --- exception caught here --- /usr/lib/python2.6/dist-packages/twisted/internet/defer.py:371:_runCallbacks beginner2.py:69:protocol /home/kwhwang/opt/lib/python/viff/passive.py:493:input /home/kwhwang/opt/lib/python/viff/passive.py:550:shamir_share /home/kwhwang/opt/lib/python/viff/runtime.py:785:_expect_share /home/kwhwang/opt/lib/python/viff/runtime.py:749:_expect_data /home/kwhwang/opt/lib/python/viff/runtime.py:754:_expect_data_with_pc As you can see, it's using shamir_share. Shamir sharing requires at least 3 players. I also modified equality.py for two players to see if it works for only two players because that file actually compared only two players' inputs but not the third player's so that file essentially needs two players. But it gaves errors too with two players. I think Viff only works with at least three players. Am I correct? Same as above :) Regards, Mikkel Krøigård ___ viff-devel mailing list (http://viff.dk/) viff-devel@viff.dk http://lists.viff.dk/listinfo.cgi/viff-devel-viff.dk
Re: [viff-devel] VIFF and random numbers
It is not good to use the wrong kind of PRG, it should be fixed as soon as possible. But do we know that os.urandom will be OK on any platform, or is this OS -dependent at the end of the day? - Ivan On 06/07/2010, at 15.22, Thomas P Jakobsen wrote: VIFF itself as well as most protocols implemented in VIFF uses the viff.util package for random number generation. This package in turn uses the random package in the Python standard library. This means that random numbers are generated using a Mersenne twister. As far as I can see, this is a problem, since Mersenne twister PRNGs are generally not suited for cryptographic usage. E.g. it is not known to pass the next-bit test and withstand the state compromise extensions, see http://en.wikipedia.org/wiki/Cryptographically_secure_pseudorandom_number_generator. One solution would be to use the os.urandom() function instead. This has specifically been designed to produce cryptographically secure random numbers. (We should probably keep the old random generator, too. It is probably faster and not all random numbers used in VIFF and VIFF programs need to be cryptographically secure.) Let me know what you think about this. Kind regards, Thomas ___ viff-devel mailing list (http://viff.dk/) viff-devel@viff.dk http://lists.viff.dk/listinfo.cgi/viff-devel-viff.dk ___ viff-devel mailing list (http://viff.dk/) viff-devel@viff.dk http://lists.viff.dk/listinfo.cgi/viff-devel-viff.dk
Re: [viff-devel] VIFF and random numbers
Indeed it should satisfy those properties. Say if you Shamir share something, the adversary might get t shares in order. If it can guess the next bit with non-negligible advantage, this will completely break our claim that the adversary has no information on the secret. Luckily it should not be hard to replace. I think we knew about this earlier but just forgot, actually. By the way, I am not sure we use any random numbers that should NOT secure in this way. Citat af Thomas P Jakobsen thomas@gmail.com: VIFF itself as well as most protocols implemented in VIFF uses the viff.util package for random number generation. This package in turn uses the random package in the Python standard library. This means that random numbers are generated using a Mersenne twister. As far as I can see, this is a problem, since Mersenne twister PRNGs are generally not suited for cryptographic usage. E.g. it is not known to pass the next-bit test and withstand the state compromise extensions, see http://en.wikipedia.org/wiki/Cryptographically_secure_pseudorandom_number_generator. One solution would be to use the os.urandom() function instead. This has specifically been designed to produce cryptographically secure random numbers. (We should probably keep the old random generator, too. It is probably faster and not all random numbers used in VIFF and VIFF programs need to be cryptographically secure.) Let me know what you think about this. Kind regards, Thomas ___ viff-devel mailing list (http://viff.dk/) viff-devel@viff.dk http://lists.viff.dk/listinfo.cgi/viff-devel-viff.dk ___ viff-devel mailing list (http://viff.dk/) viff-devel@viff.dk http://lists.viff.dk/listinfo.cgi/viff-devel-viff.dk
Re: [viff-devel] VIFF and random numbers
Thomas P Jakobsen wrote: The urandom is os-specific: This function returns random bytes from an OS-specific randomness source. The returned data should be unpredictable enough for cryptographic applications, though its exact quality depends on the OS implementation. On a UNIX-like system this will query /dev/urandom, and on Windows it will use CryptGenRandom. I don't know whether this will be good enough. There is a paper describing various flaws: http://www.pinkas.net/PAPERS/gpr06.pdf If not, I guess we'll have to use some external package (openssl?) or implement our own algorithm. viff.util.rand is used to make all randomness replayable, which already helped me to find bugs triggered by certain randomness. I would like to have this feature also in the future, therefore I would vote against a random number generator using noise not only to generate a seed. If the environment variable VIFF_SEED is set to the empty string, VIFF already uses /dev/urandom by using random.SystemRandom for random number generation. This possibility is not documented however. Best regards, Marcel On Tue, Jul 6, 2010 at 15:40, Ivan Bjerre Damgård i...@cs.au.dk wrote: It is not good to use the wrong kind of PRG, it should be fixed as soon as possible. But do we know that os.urandom will be OK on any platform, or is this OS -dependent at the end of the day? - Ivan On 06/07/2010, at 15.22, Thomas P Jakobsen wrote: VIFF itself as well as most protocols implemented in VIFF uses the viff.util package for random number generation. This package in turn uses the random package in the Python standard library. This means that random numbers are generated using a Mersenne twister. As far as I can see, this is a problem, since Mersenne twister PRNGs are generally not suited for cryptographic usage. E.g. it is not known to pass the next-bit test and withstand the state compromise extensions, see http://en.wikipedia.org/wiki/Cryptographically_secure_pseudorandom_number_generator. One solution would be to use the os.urandom() function instead. This has specifically been designed to produce cryptographically secure random numbers. (We should probably keep the old random generator, too. It is probably faster and not all random numbers used in VIFF and VIFF programs need to be cryptographically secure.) Let me know what you think about this. Kind regards, Thomas ___ viff-devel mailing list (http://viff.dk/) viff-devel@viff.dk http://lists.viff.dk/listinfo.cgi/viff-devel-viff.dk ___ viff-devel mailing list (http://viff.dk/) viff-devel@viff.dk http://lists.viff.dk/listinfo.cgi/viff-devel-viff.dk ___ viff-devel mailing list (http://viff.dk/) viff-devel@viff.dk http://lists.viff.dk/listinfo.cgi/viff-devel-viff.dk
Re: [viff-devel] VIFF and random numbers
I agree that tests should be reproducible. But it is also very important to use a cryptographically secure PRNG. I don't know whether these two requirements can be satisfied by the same number generator. If not, the best solution is to have two modes of operation: - A test mode where the execution can be reproduced and - a secure mode using a cryptographically secure PRNG Regards, Thomas ___ viff-devel mailing list (http://viff.dk/) viff-devel@viff.dk http://lists.viff.dk/listinfo.cgi/viff-devel-viff.dk
Re: [viff-devel] VIFF reactor
Marcel Keller mkeller at cs.au.dk writes: Hi Joel, Is it still necessary to run `viff.reactor.install()` as described in http://www.mail-archive.com/viff-devel at viff.dk/msg00657.html in order to utilize the VIFF reactor? - If so, would it be possible to fix that? I don't see a good way to that, for the following reasons: - To change the default reactor properly, it would be necessary to change the Twisted source code. That is not an elegant way. - The VIFF reactor could be installed in the runtime module. However, if it would be done that way, viff.runtime would have to be imported before importing the reactor, which is a possible source of errors. Furthermore, that would prevent other reactors like the GtkReactor from being used. - If not, then the example apps would need to be updated accordingly. As far as I can see, all example apps are updated in VIFF 1.0. Best regards, Marcel Hi Marcel, I see. Thanks for your quick reply! And yes, since it really is necessary to run `viff.reactor.install()` manually before `from twisted.internet import reactor` you are absolutely right — all example apps are up-to-date. Best regards, Joel Pettersson ___ viff-devel mailing list (http://viff.dk/) viff-devel@viff.dk http://lists.viff.dk/listinfo.cgi/viff-devel-viff.dk
Re: [viff-devel] VIFF reactor
Hi Joel, Is it still necessary to run `viff.reactor.install()` as described in http://www.mail-archive.com/viff-devel@viff.dk/msg00657.html in order to utilize the VIFF reactor? - If so, would it be possible to fix that? I don't see a good way to that, for the following reasons: - To change the default reactor properly, it would be necessary to change the Twisted source code. That is not an elegant way. - The VIFF reactor could be installed in the runtime module. However, if it would be done that way, viff.runtime would have to be imported before importing the reactor, which is a possible source of errors. Furthermore, that would prevent other reactors like the GtkReactor from being used. - If not, then the example apps would need to be updated accordingly. As far as I can see, all example apps are updated in VIFF 1.0. Best regards, Marcel ___ viff-devel mailing list (http://viff.dk/) viff-devel@viff.dk http://lists.viff.dk/listinfo.cgi/viff-devel-viff.dk
Re: [viff-devel] VIFF reactor
Joel Pettersson joel...@kth.se writes: Hi everybody, Is it still necessary to run `viff.reactor.install()` as described in http://www.mail-archive.com/viff-devel@viff.dk/msg00657.html in order to utilize the VIFF reactor? - If so, would it be possible to fix that? - If not, then the example apps would need to be updated accordingly. I see Marcel answered this with lightning speed, cool! :-) I will, by the way, be available in #viff @ Freenode most of my time the next couple of days. I'll like to add that it's very easy to get online: http://webchat.freenode.net/ -- Martin Geisler aragost Trifork Professional Mercurial support http://aragost.com/mercurial/ ___ viff-devel mailing list (http://viff.dk/) viff-devel@viff.dk http://lists.viff.dk/listinfo.cgi/viff-devel-viff.dk
Re: [viff-devel] VIFF 1.0 this weekend
And mine is here: http://daim.idi.ntnu.no/masteroppgave?id=4559 Put it anywhere you like! håvard atl...@stud.ntnu.no wrote: Siterer Martin Geisler m...@lazybytes.net: Hi everybody, I would like to release what we currently have in VIFF as version 1.0 this weekend. The code has not evolved very much the last year, and releasing version 1.0 now will fit nicely with the reports we're writing for CACE and with my own dissertation :-) As preparation for that, I've made a small document about the applications where VIFF has been used: http://viff.dk/doc/applications.html Atle and Håvard: do you have your thesis' online somewhere? I would like to include links to them. I have your thesis' in PDF format already, so I would also be happy to host them on viff.dk if you prefer that? My thesis can be found at http://daim.idi.ntnu.no/masteroppgave?id=4699, also feel free to host it on the VIFF page :) Everybody: if someone wants to describe the Nordic Sugar auction then that would be super, otherwise I'll do it. Marcel has promissed to write something about the distributed RSA. Finally, if you have been sitting on a bugfix (small or large), then please put it in now :-) -- Martin Geisler VIFF (Virtual Ideal Functionality Framework) brings easy and efficient SMPC (Secure Multiparty Computation) to Python. See: http://viff.dk/. ___ viff-devel mailing list (http://viff.dk/) viff-devel@viff.dk http://lists.viff.dk/listinfo.cgi/viff-devel-viff.dk
Re: [viff-devel] [viff-commits] viff: Generate_config_files:Added support NaCl implementation of...
Some good old-fashioned code review coming up... :-) Great! /rev/736ad1d97024 changeset: 1361:736ad1d97024 user: Janus Dam Nielsen janus.niel...@alexandra.dk date: Wed Oct 28 14:53:51 2009 +0100 summary: Generate_config_files:Added support NaCl implementation of Paillier. There's a space missing after the colon. Ok. diffstat: apps/generate-config-files.py | 22 +++--- viff/paillierutil.py | 20 +++- 2 files changed, 38 insertions(+), 4 deletions(-) diffs (90 lines): diff -r 3fe6e03541c1 -r 736ad1d97024 apps/generate-config-files.py --- a/apps/generate-config-files.py Wed Oct 28 14:53:49 2009 +0100 +++ b/apps/generate-config-files.py Wed Oct 28 14:53:51 2009 +0100 @@ -55,7 +55,17 @@ from optparse import OptionParser from viff.config import generate_configs -from viff.paillierutil import ViffPaillier +from viff.paillierutil import ViffPaillier, NaClPaillier + +try: +import pypaillier +except ImportError: +pypaillier = None Are we getting a module called 'pypaillier' alongside the old module called 'paillier'? I don't like that name very much. Perhaps we should make a module called nacl so that you could do try: from viff.nacl import paillier except ImportError: from viff import paillier and then make the interface identical for the two modules. Agree, this is a goal to be pursued soonish, but I would like Marc to make a distribution of his work that can be accessed somewhere on the internet. I believe the interfaces are identical Also, can we please have that code put into VIFF? I don't like it that we're getting more and more secret code floating around :-) Especially not when we make changes to VIFF to accomodate this secret code -- it would be different if we had simple drop-in Python replacements for it. (I know you've said that this code can be made public since it's part of NaCL, so this is more for the record...) The code will not be a part of VIFF, but a prerequisite like Zope interfaces or Twisted. I will issue warning on the mailling list when I submit the changeset that will require it. + +paillier_choices = ['viff'] + +if pypaillier: +paillier_choices += ['nacl'] The append method is better for that. Ok. +paillier = ViffPaillier(options.keysize) +if nacl == options.paillier: +paillier = NaClPaillier(options.keysize) I think it's clearer if you write if options.paillier == nacl: paillier = NaClPaillier(options.keysize) else: paillier = ViffPaillier(options.keysize) I slightly disagree. if nacl == options.paillier: paillier = NaClPaillier(options.keysize) else: paillier = ViffPaillier(options.keysize) Is more natural in the current case. +try: +import pypaillier +except ImportError: +pypaillier = None + + class Paillier: def __init__(self, keysize): @@ -35,8 +41,20 @@ def generate_keys(self): return paillier.generate_keys(self.keysize) + +class NaClPaillier: + +def __init__(self, keysize): +self.keysize = keysize +self.type = 'nacl' + +def generate_keys(self): +return pypaillier.generate_keys(self.keysize) def deserializer(paillier_type, str): -return tuple(map(long, str)) +if paillier_type == viff: +return tuple(map(long, str)) +if paillier_type == nacl: +return str.dict() I think that function would belong in the otherwise unnecessary classes you define above? Or even better: make a function in two different modules like I suggest above. This is a good question. I choose the current design because it leaves you with only one place you should change if you want to add another paillier implementation. I need to think some more before I comment further on this. Janus Dam Nielsen Research and Innovationspecialist, PhD. CENTRE FOR IT-SECURITY THE ALEXANDRA INSTITUTE LTD. T +45 42 22 93 56 E janus.niel...@alexandra.dk W alexandra.dk ___ viff-devel mailing list (http://viff.dk/) viff-devel@viff.dk http://lists.viff.dk/listinfo.cgi/viff-devel-viff.dk
Re: [viff-devel] viff 0.7.1 question
Hi, I hope this question is not a bother to you. No, not at all I was trying to test viff-0.7.1, as I executed generate-config-files.py, I got the error ¨ImportError: No module named viff.config¨. Im not sure how to fix this problem. Most likely viff is not yet on your PYTHONPATH Please read: http://viff.dk/doc/install.html#installing-from-source for instructions on how to get it there. On Tue, Oct 20, 2009 at 2:27 PM, Angel Redoble angel_redo...@yahoo.com wrote: Im using ubuntu 9.04. Thanks a lot. Angel ___ viff-devel mailing list (http://viff.dk/) viff-devel@viff.dk http://lists.viff.dk/listinfo.cgi/viff-devel-viff.dk Sigurd ___ viff-devel mailing list (http://viff.dk/) viff-devel@viff.dk http://lists.viff.dk/listinfo.cgi/viff-devel-viff.dk
Re: [viff-devel] VIFF benchmarks
Thomas Jakobsen thomas@gmail.com writes: Hi Thomas I've written a VIFF application that should make it easy to create, run and visualize benchmarks for VIFF protocols. I've put some changes to it here -- it's only style changes in order to make it more pythonic :-) Please pull from this repository: http://bitbucket.org/mg/viffbench-mg/ I have not really tested the changes, expect by running pyflakes on the source. By the way, pyflakes informs me that: viffbench/examples/ComparisonToft05.py:68: undefined name 'start_time' viffbench/lib/enum.py:193: undefined name 'EnumValueCompareError' viffbench/test/test.py:52: undefined name 'Suite' in addition to some warnings. I hope you like the changes, and that they mostly work! :-) -- Martin Geisler VIFF (Virtual Ideal Functionality Framework) brings easy and efficient SMPC (Secure Multiparty Computation) to Python. See: http://viff.dk/. pgps7KXCgLzkV.pgp Description: PGP signature ___ viff-devel mailing list (http://viff.dk/) viff-devel@viff.dk http://lists.viff.dk/listinfo.cgi/viff-devel-viff.dk
Re: [viff-devel] viff: Switch to prss_share_bit_double in comparisons.
Ivan Bjerre Damgaard [EMAIL PROTECTED] writes: Quoting Martin Geisler [EMAIL PROTECTED]: .. but this makes viff.test.test_runtime_comp.ActiveToft05GreaterThanEqualTest go into what looks like a never-ending loop?! You you have a better solution, then I'm all ears! :-) What is wrong with just doing a single normal secure multiplication, and then open the result? That was what I tried to do... I don't know why it didn't work. I have now created Issue 42 to track this: http://tracker.viff.dk/issue42 Who wants to have the honor of fixing bug 42?! :-) -- Martin Geisler ___ viff-devel mailing list (http://viff.dk/) viff-devel@viff.dk http://lists.viff.dk/listinfo.cgi/viff-devel-viff.dk
Re: [viff-devel] viff: Switch to prss_share_bit_double in comparisons.
Quoting Martin Geisler [EMAIL PROTECTED]: .. but this makes viff.test.test_runtime_comp.ActiveToft05GreaterThanEqualTest go into what looks like a never-ending loop?! You you have a better solution, then I'm all ears! :-) What is wrong with just doing a single normal secure multiplication, and then open the result? If we want to optimize, we have to have a way to PRSS-create a random degree 2t polynomial that is 0 in 0. This is close to what we discussed at the meeting today. Given that, we first make a random shared a, and a random degree 2t polynomial g, with g(0)=0. Then locally square your share in a, add to your share in g and broadcast. This will securely compute a^2, with passive security if t n/2. If you want active security, it's more complicated, and it may be easier as a first step to just call a normal multiplication to get a^2. Then you get whatever security that multiplication offers. regards, Ivan regards, Ivan ___ viff-devel mailing list (http://viff.dk/) viff-devel@viff.dk http://lists.viff.dk/listinfo.cgi/viff-devel-viff.dk
Re: [viff-devel] viff: Switch to prss_share_bit_double in comparisons.
Hi Martin Geisler wrote: viff-devel@viff.dk writes: Hi everybody, I don't know how many of you follow the commits to the VIFF repository? Would anybody be interested in a mailing list for it? Anyway -- the latest commit is this: http://hg.viff.dk/viff/rev/5dd8c277268c changeset: 751:5dd8c277268c user: Martin Geisler [EMAIL PROTECTED] date: Tue May 13 16:28:41 2008 +0200 summary: Switch to prss_share_bit_double in comparisons. This change makes the ComparisonToft05Mixin.greater_than_equal method actively secure and much faster! Running three players on my home computer gives these results: Before: 1309 ms per comparison with 100 parallel comparisons After: 324 ms per comparison with 100 parallel comparisons That is a factor of four! I measured similar improvements earlier today when using three different machines at DAIMI. Nice speedup. It's also possible to do a similar thing for ComparisonToft07Mixin. In the two-fields variation we need the same bit in Zp and Zq, where qp, say p is 500-bit and q=3001. Similarly to generating the same random bit in Zp and GF(256), we can 1) generate a random bit [b]_p in Zp 2) generate a pseudorandom number [r]_p (of limited size) in Zp and the same number mod q in Zq [r mod q]_q (similar to the present case, where q implicitly is two) 3) c - open([b]_p + [r]_p) 4) [b]_q = ((c mod q) - [r mod q]_q) Anyway. looking at this lead Mikkel and me to look at prss_share_random in runtime.py, and there seems to be either a bug (information leak) /or/ a possibility of optimisation when sharing a bit in Zp. The problem is the following: result = self.open(Share(self, field, share*share), threshold=2*self.threshold) Is the * in share*share a multiplication protocol or a multiplication of actual values? If it is actual values, then we *cannot* simply call it shares and open it, as the polynomial is not uniformly random (this can also be done with PRSS and no communication). If on the other hand it is an invoation of the multiplication protocol, then it is secure but can be optimised with the PRSS version mentioned above. Regards, Tomas ___ viff-devel mailing list (http://viff.dk/) viff-devel@viff.dk http://lists.viff.dk/listinfo.cgi/viff-devel-viff.dk
Re: [viff-devel] VIFF unit tests
Janus Dam Nielsen [EMAIL PROTECTED] writes: I think that having parametrized tests is good, however I just wanted to point out that defining the parameters in the Runtime class/object might not be suffienciently expressive to what we want. We might would like a kind of grouping/system of tests so that it is easy to run the tests without any particular knowledge of which protocols support which parameters. Those tests for which a given set of parameters is invalid, the test could return an undefined value, or the test could be elided from the set of tests since it doesn't make any sense for these parameters anyhow. The test suite is implemented using Trial, a Twisted tool which extends the standard Python unittest module with support for Deferreds. The Python unittest module is modelled after JUnit. In Trial there is support for marking a test as skipped, and that might be useful for what you are describing -- we could query the tests for their requirements and if they do not match the parameters of the current test, then we skip that test. Something like that could work, but I don't know if it is the best way... Have you looked at the Trial documentation to see how it could be done? There is a tutorial here: http://twistedmatrix.com/trac/browser/branches/trial-tutorial-2443/doc/core/howto/trial.xhtml?format=raw and the API documentation is here: http://twistedmatrix.com/documents/current/api/twisted.trial.unittest.TestCase.html Trial is not so well documented as the rest of Twisted, so looking at the source code has helped me a bit until I found the above tutorial. -- Martin Geisler ___ viff-devel mailing list (http://viff.dk/) viff-devel@viff.dk http://lists.viff.dk/listinfo.cgi/viff-devel-viff.dk
Re: [viff-devel] VIFF unit tests
Janus Dam Nielsen [EMAIL PROTECTED] writes: Does it make sense to run all unit tests with the same configuations of players and thresholds. That is, for all protocols p, is p executed with x players and threshold t is p welldefined? Well, no, not in general. If you write a protocol for seven people Shamir sharing would look like this in VIFF: a, b, c, d, e, f, g = rt.shamir_share(range(1, 8), input) and that breaks down (I guess quite spectacularly...) when you run it with fewer than seven players. I think Thomas wants us to write protocols that are generic in the sense that they don't assume a particular number of players. So the above line becomes: shares = rt.shamir_share(range(1, len(rt.players)+1), input) If the next step is to add all inputs, then this is easily changed from sum = a + b + c + d + e + f + g to import operator sum = reduce(operator.add, shares) which works any number of shares. So it is only carefully written protocols that can be adapted like that. Examples could be: * Find the minimum input, the median input, the sum, or the average. * Sort the inputs (using a simple bubble-sort or similar). The Yao millionaires example already sorts three elements via three comparisons. -- Martin Geisler ___ viff-devel mailing list (http://viff.dk/) viff-devel@viff.dk http://lists.viff.dk/listinfo.cgi/viff-devel-viff.dk
Re: [viff-devel] VIFF 0.3 has been released!
Janus Dam Nielsen [EMAIL PROTECTED] writes: Hi Janus That is great news! As expected, the time per multiplication stayed constant when I varied the number of multiplications -- with the parallel scheduling there is a huge difference between doing 100 and doing 1000 multiplications (a factor of four in a test I did). Do you have any idea about why there is a factor of four? No, I'm afraid that I can only guess... This is the table I was able to make some days ago for parallel multiplications: +-+--+ | Number of muls | Time per mul | +-+--+ | 100 | 16.6 ms | +-+--+ | 500 | 6.8 ms | +-+--+ | 1000| 4.0 ms | +-+--+ | 3000| 2.9 ms | +-+--+ When I tested sequential multiplications I got timings of 190 ms per multiplication. When I do a traceroute from viff.dk to the computer in Norway, it also measures a round trip time of ~190 ms (14 hops). In theory, I would expect the parallel multiplications to take at least 190 ms and when the CPU fully loaded and the bandwidth exhausted, the time should increase linearly. Something like this (in my poor ASCII art skills): ^ |_- | _- |_- 190 | | +--- ^ full load The average time per multiplication would then of course drop quickly until the full load point, and from there on it should grow/fall until it stabilizes on the true average. This is just my expectation, I have not done enough tests to really confirm it yet. (Testing is takes a lot of time and somewhat boring :-) With the latest changes in the code I'm seeing more fluctuations in the test results -- I don't know why that is. The slowest host is viff.dk and it is normally twice as slow as the other two machines. I've just tried running benchmark.py with 1000 multiplications: camel25: 1.165 ms viff.dk: 3.196 ms serengeti12: 1.364 ms When I ran a similar test with 1000 multiplications using the old multiply_benchmark.py a week ago, I got numbers like this: thyra03: 3.188 ms viff.dk: 3.357 ms serengeti12: 3.818 ms These numbers are much more similar. I'll have to look into why the new test gives different timings for the different players. -- Martin Geisler ___ viff-devel mailing list (http://viff.dk/) viff-devel@viff.dk http://lists.viff.dk/listinfo.cgi/viff-devel-viff.dk
