Re: [viff-devel] VIFF needs at least 3 players always?
Citat af Kyung-Wook Hwang : 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: : 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 --- --- /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
[viff-devel] Comparison problems
Hello, We've been trying to run an MPC LP solver (by Tomas Toft) for a while now and can't get it to work for examples of a more realistic size. One problem we're having right now is that using the Toft07 comparison, we can basically get VIFF to drop to 0% CPU usage and just sit there forever. What we did was run the "compare.py" test program from viff/apps but with Toft07 instead of Toft05, and with different bit lengths. Running it with anything up to and including 968 seems to work. 969 and beyond apparently makes VIFF freeze. If anyone has any ideas or can tell us what exactly we're doing wrong, it would be much appreciated. ___ viff-devel mailing list (http://viff.dk/) viff-devel@viff.dk http://lists.viff.dk/listinfo.cgi/viff-devel-viff.dk
Re: [viff-devel] Say hello to viff.boost
Citat af Marcel Keller : Hi friends of VIFF, I've implemented Share and ShareList in C, based on a C implementation of Deferred. Using the C extension, benchmark.py and aes.py show a speed up between 50 and 100 percent. This is very nice, but not entirely surprising I think. I believe this other MPC project that claimed to be much faster than VIFF was also written in C. There is simply much room for optimization, and you can probably imagine that having everything written in highly optimized C code would make it faster still. Their reasoning, on the other hand, was that the asymptotic nature of VIFF was causing it to be slower. I am still not convinced about that. The code is in my repository: http://hg.viff.dk/mkeller To use the extension, first compile and install it: $ python setup.py install [--prefix PREFIX] Then, add the following lines two to your program before importing anything from viff or twisted: import viff.boost viff.boost.install(with_viff_reactor=) If the parameter is True, the VIFF reactor is also installed, so this doesn't have to be done separately. There is a notable difference to the standard implementation of Deferred: Errbacks are disabled and exceptions raised in callbacks are not caught. This is for the following reasons: - The implementation was inefficient (too many isinstance() calls). - Errbacks are only used for error reporting in VIFF. However, I prefer VIFF to crash (and print a traceback) immediately if there is an exception instead of wrapping the exception and reporting it later, which makes debugging harder. Honestly I would too. That said, I haven't really been debugging VIFF so who am I to argue :) I'm open for comments on this issue. It shouldn't be hard to reimplement errbacks or to implement something different like a global errback. For compatibility, all Deferred methods are still present. If trial is modified to load the C extension, all tests succeed except a few doctests. Best regards, Marcel ___ 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
Of course it is also worth mentioning that this is a very quick and dirty implementation of BBS. I am sure you can save a lot of time by implementing this in a clever way. No tricks were used except for gmpy. Citat af Mikkel Krøigård : By the way, I just implemented the Blum Blum Shub generator in Python just to see how fast it would be compared to urandom. Note here that urandom is significantly slower than the default Python PRNG, but we can't use the normal one anyway. The BBS generator must square modulo n (product of two Blum primes) and then extract log log n lower-order bits from that. I picked a 2048 bit n and extracted 10 bits per squaring. I then generated 10 random bits a million times using urandom and BBS: urandom: 30 seconds BBS: 80 seconds Not THAT bad really. This is the ideal situation for BBS though. However, if you use for example random() instead (random float in [0;1) ), then you must either pool bits (which takes time) or throw away bits per call, because you need about 53 bits per number (I'm assuming they ARE double-precision, not a Python geek :) ). There I got: urandom: 29 seconds BBS: 435 seconds (not surprising, since 80*6 = 420) This is of course horrible. PS: There are probably better crypto-secure PRNGS out there, I just picked BBS because I know that one quite well. Also, the CryptGenRandom generator in Windows is claimed to have been patched and fixed for Windows XP and Vista (presumably Windows 7 too). However, it's probably not good practice to take their word for it :) Citat af Thomas P Jakobsen : 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 ___ 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
By the way, I just implemented the Blum Blum Shub generator in Python just to see how fast it would be compared to urandom. Note here that urandom is significantly slower than the default Python PRNG, but we can't use the normal one anyway. The BBS generator must square modulo n (product of two Blum primes) and then extract log log n lower-order bits from that. I picked a 2048 bit n and extracted 10 bits per squaring. I then generated 10 random bits a million times using urandom and BBS: urandom: 30 seconds BBS: 80 seconds Not THAT bad really. This is the ideal situation for BBS though. However, if you use for example random() instead (random float in [0;1) ), then you must either pool bits (which takes time) or throw away bits per call, because you need about 53 bits per number (I'm assuming they ARE double-precision, not a Python geek :) ). There I got: urandom: 29 seconds BBS: 435 seconds (not surprising, since 80*6 = 420) This is of course horrible. PS: There are probably better crypto-secure PRNGS out there, I just picked BBS because I know that one quite well. Also, the CryptGenRandom generator in Windows is claimed to have been patched and fixed for Windows XP and Vista (presumably Windows 7 too). However, it's probably not good practice to take their word for it :) Citat af Thomas P Jakobsen : 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 and random numbers
I had not seen the later replies before answering. My apologies. The way I've always understood urandom is exactly that. It's "probably" unpredictable but there's no actual proof of this, like there would be if you used for example Blum Blum Shub. I'm sure there are multiple implementations of cryptographically secure PRNGs floating around. I think I even have one in Java. I suspect they are much slower than urandom though. Citat af Thomas P Jakobsen : 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. If not, I guess we'll have to use some external package (openssl?) or implement our own algorithm. Regards, Thomas On Tue, Jul 6, 2010 at 15:40, Ivan Bjerre Damgård 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
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 : 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] The primitives of MPC
I think it deserves to be mentioned that you can do conditional statements on secret values in some cases. A simple case is easy to implement with the other primitives, but then of course you can be annoying and start nesting them. Citat af Sigurd Torkel Meldgaard : Other nice 2. order operations are bitsplitting (and also recombination of the bits) and multiplicative inverse (works only if you can guarantee a non-zero element) And when you have the bits you would also like logic negation, xor, and and or. - Sigurd On Tue, Aug 25, 2009 at 9:22 AM, Tord Ingolf Reistad wrote: If you boil down VIFF, or any MPC program you can boil it down to 5 primitives. These primitives are x + y = z Addition x * y = z Multiplication -x = z Negation z = Share(x) Secret sharing z = Reveal(x) Revealing of a secret sharing My question is now: What are the second order primitives? What are the basic features that, make a programmers life easy but not essential. I would propose the following 5: z = f(x,y) Function calls for(0 to n) A for call with a fixed number of iterations. z = Rand(x) Generating random values in Zp x = y Equation x < y Comparison while( x ) A while loop on x, where x is a revealed value The first 2 primitives are easy since they are already implemented using the underlying programming language. Should creating random values be on this list? Or should it maybe be among the first order primitives, a basic building block of MPC. Equation and comparison are obvious second order primitives and has been my research topic for many years. The last on the list is the while loop, I have included it because I have seen many times that you want to compute some function, open a variable, check some information and then redo the function if the revealed value was false. This can be found when creating random values less than some threshold, creating RSA primes, and many other algorithms. Also it is not trivial to program if you want it to be efficient. ___ 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] A java implementation of VIFF
Citat af Tord Ingolf Reistad : Hello, As some of you might know I have not programmed that much in VIFF because I am more familiar with C++ and Java than Python as a programming language. Therefore I have now created a Java rival to VIFF. Taking all the good design principles from VIFF and adding some things that VIFF cannot offer such as multi-threading. I have taken a look at the code. It's a bit hard to follow without further explanation, but I think I understand the basics. At least it seems like I wouldn't have a hard time writing small MPC programs using your code (MPCTestAlgorithm certainly looks quite simple). As Thomas has suggested, yes it would be fun to see benchmark comparisons with VIFF. When VIFF was designed, I don't think it was the idea to skip multithreading with the knowledge that it would be worse or slower. A thorough comparison of both schemes could help show if there are any clear advantages to either of them. I hereby volunteer someone else to do all the work :) The program still has one drawback, in that the different players communicate over Java queues, and these queues cannot communicate through sockets. Therefore it is not a complete MPC implementation. This part sounds a bit odd to be honest. The whole program was programmed and tested in just 34 hours (including 6 hours sleep). It contains 2115 lines of code and 32 classes Ouch :) ___ viff-devel mailing list (http://viff.dk/) viff-devel@viff.dk http://lists.viff.dk/listinfo.cgi/viff-devel-viff.dk
Re: [viff-devel] Player thresholds
Citat af Håvard Vegge :
Thanks for clarifying!
Guess there are a lot of different variations of the definitions,
notions, etc. regarding secret sharing and MPC...
One of my problems is that when running the included sort.py
protocol with n=5 and t=2, the sorting of the array fails:
Original array: [{33}, {61}, {95}, {67}, {37}]
Sorted array: [{6692966529242218069}, {35128728804386641877},
{6621921405115695795}, {27880759555216652877}, {34356088148296101764}]
Made 9 comparisons
Works with n=5 and t=1 though...
That definitely looks like a bug to me. It has been about forever
since I looked at the VIFF code, but I think I'll try this out, see if
I can get the bug as well.
Mikkel Krøigård wrote:
Citat af Håvard Vegge :
Hi!
I'm trying to do some basic benchmarks with different number of
players. A few questions:
1. Why have VIFF defined the threshold t to be the number of
corrupt players, while the classical literature defines it as "t
participants can reconstruct the message"?
Well, in what I have read, it is most often referred to as the
threshold for the number of tolerated corruptions, though yes I
have also seen it described as the number of shares needed to
reconstruct. I don't think there's anything wrong with the way we
do it, as long as it is clearly defined.
2. Say I create the config files this way:
python generate-config-files.py -n 5 -t 2 localhost:9001
localhost:9002 localhost:9003 localhost:9004 localhost:9005
Would this indicate that the polynomial is quadratic (of degree 2)
and that 3 players in theory could reconstruct some secret?
Yes.
3. Assume three of these five players provide input, while the
last two players do not. Will all players still participate in the
actual computation, or are the last two just passive spectators
and receives only the output?
-n 5 indicates that 5 servers will participate, regardless of how
many will provide input. Think of it from the perspective of
security. If the input was shared to 3 servers, we could not
tolerate 2 corruptions.
___
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] Player thresholds
Citat af Håvard Vegge : Hi! I'm trying to do some basic benchmarks with different number of players. A few questions: 1. Why have VIFF defined the threshold t to be the number of corrupt players, while the classical literature defines it as "t participants can reconstruct the message"? Well, in what I have read, it is most often referred to as the threshold for the number of tolerated corruptions, though yes I have also seen it described as the number of shares needed to reconstruct. I don't think there's anything wrong with the way we do it, as long as it is clearly defined. 2. Say I create the config files this way: python generate-config-files.py -n 5 -t 2 localhost:9001 localhost:9002 localhost:9003 localhost:9004 localhost:9005 Would this indicate that the polynomial is quadratic (of degree 2) and that 3 players in theory could reconstruct some secret? Yes. 3. Assume three of these five players provide input, while the last two players do not. Will all players still participate in the actual computation, or are the last two just passive spectators and receives only the output? -n 5 indicates that 5 servers will participate, regardless of how many will provide input. Think of it from the perspective of security. If the input was shared to 3 servers, we could not tolerate 2 corruptions. ___ viff-devel mailing list (http://viff.dk/) viff-devel@viff.dk http://lists.viff.dk/listinfo.cgi/viff-devel-viff.dk
Re: [viff-devel] [issue80] Broadcast
Citat af Ivan Bjerre Damgård : It can definitely be useful to have a broadcast method, for instance to complete the implementation of the asynchronous maliciously secure protocol, we will need broadcast. But one needs to be careful about what kind of security we want. There is a whole jungle of protocols, depending on whether it is unconditional or computational security, synchronous or asynchronous network, and what number of players you assume can be corrupt. I think a protocol of Bracha has in fact already been implemented in VIFF Indeed it has. It's located in the active runtime (active.py). ___ viff-devel mailing list (http://viff.dk/) viff-devel@viff.dk http://lists.viff.dk/listinfo.cgi/viff-devel-viff.dk
Re: [viff-devel] Mystery of the quadratic running time solved?
Citat af Marcel Keller : Indeed we did not know (well I didn't) back then that the data was not sent immediately by Twisted, and I was starting to think yesterday whether the hack would make a difference. Lucky for us, it apparently does :) That is not the only problem. To free the memory of the shares and to send out further shares, also the incoming shares must be processed as soon as possible. This is even trickier because incoming shares might trigger code that calls functions sending out data, which activates the Twisted reactor again and therefore leads to a possibly too deep recursion. I think I have a solution for that, it just wasn't necessary to implement it for now because the hack worked anyway. Ah, but the numbers I had been shown did not indicate we were anywhere near running out of memory. That's not to say memory isn't important (it certainly will be in cases with huge amounts of operations), I just didn't think it had anything to do with our specific test cases for the paper. ___ viff-devel mailing list (http://viff.dk/) viff-devel@viff.dk http://lists.viff.dk/listinfo.cgi/viff-devel-viff.dk
Re: [viff-devel] Mystery of the quadratic running time solved?
Citat af Ivan Bjerre Damgård : Very interesting! So if things are as they seem here, the explanation for the strange behavior would be that the precomputing phase, being more involved than the online phase, is punished by Twisted (when unhacked). And this is of course not included in the analysis in the paper. Yes. Very interesting, and nice work Marcel. Indeed we did not know (well I didn't) back then that the data was not sent immediately by Twisted, and I was starting to think yesterday whether the hack would make a difference. Lucky for us, it apparently does :) regards, Ivan Quoting Marcel Keller : Hello friends of VIFF, I've now run the benchmark of actively secure multiplications with hyperinvertible matrices together with my hack. Here are my results (column 1 and 2) compared to the results in the paper "Asynchronous Multiparty Computation: Theory and Implementation" (column 3 and 4): (n,t) online preprocessing online preprocessing (4,1) 5 18 4 20 (7,2) 7 30 6 42 (10,3) 9 43 8 82 (13,4) 12 56 10 136 The preprocessing time now seems to be linear whereas the online time is slightly increased. I didn't benchmark bigger thresholds because it's difficult enough find 13 camels which are not hard ridden yet. I think I also fixed the increased online time, but I couldn't test the fix thoroughly because the active adversaries continuously change the corrupted camels. Again, there are two patches in the attachement, and again, the patch for VIFF is against the current tip of my repository: http://hg.viff.dk/mkeller/rev/e2759515f57f Best regards, Marcel ___ 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] Off topic question "multiparty" or "multi-party"
Quoting Ivan Bjerre Damgård : Quoting Tord Ingolf Reistad : Hello, An off topic question about how to write "Secure Multiparty Compuations", should it be "multiparty" or "multi-party" The front page of VIFF.dk uses "multi-party", but resent papers such as "Multiparty computation goes live" uses the other version. So which should we go for, which should be the standard? David Chaum once told me that it's "multiparty" and he's American, so I guess he should know.. Here's an argument that doesn't involve having a pocket American (no offense to mr. Chaum of course): A quick look at the dictionary reveals that you can find the word "multiparty" there (although it has a political meaning). You could suspect that the spelling multi-party would be fine as well, and maybe it is, but I'm guessing it would not be standard, since other words starting with "multi" do not use the hyphen: multicolo(u)red, multifaceted, multinational and so on. ___ viff-devel mailing list (http://viff.dk/) viff-devel@viff.dk http://lists.viff.dk/listinfo.cgi/viff-devel-viff.dk
Re: [viff-devel] ohloh has spoken
Citat af Martin Geisler : Hi guys, Take a look at this: we're in the top 10% of all Python projects: https://www.ohloh.net/p/viff/factoids/1178198 Wow. Very nice! ___ 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 large scale programs -- is VIFF really asynchronous?
Quoting Ivan Bjerre Damgård : Folks, I think your precious time is better spent on figuring out a brilliant solution to handling memory issues with VIFF, than on discussions about what "asynchronous" really means :-) Well if you are calling it asynchronous, then it had better BE asynchronous :) However, the focus is on handling the memory issue. While you can save memory by splitting up the computation, I would much prefer it if you could write code like the stuff Tomas wrote without thinking about memory-saving tricks. Ideally, it should be completely straightforward and without tricks. We just discussed if the Twisted reactor could somehow get control before we are done scheduling. In the case below, we would like to start getting some of the older stuff done before piling on new computations, and if the reactor could just send and receive once in a while, then maybe that could happen. However, Twisted is apparently not the kind of scheduling system we would need for that. I guess my question for this list is if my understanding here is correct. Martin told me that there may be a way to reduce the memory usage by minimizing the size of deferreds, and that this is already mentioned in the bug tracker. However, add an extra zero to the number of iterations and we're back to square one. regards, Ivan Quoting Marcel Keller : A really unpleasant thought has occurred to me: Is VIFF really properly asynchronous? (Yes, this question is intended to provoke you into thinking about the issue below. Of course VIFF is asynchronous in the sense that there are no rounds.) If I understand/remember correctly, VIFF is 100% single threaded. This means that if we have a small program: x, y = runtime.shamir_share([1, 2], Zp, input) z = x*y for i in xrange(100): z=z*z 1) We first share two values (returning immediately). There's a pitfall here: What do you mean with "share"? At this point, the shares are only scheduled to be sent, the real communication doesn't occur until step 3. The FAQ of Twisted says so: http://twistedmatrix.com/trac/wiki/FrequentlyAskedQuestions#WhydoesittakealongtimefordataIsendwithtransport.writetoarriveattheothersideoftheconnection Since I discussed this issue last week with Martin, I also looked at the source of Twisted 8.1.0 to confirm it. 2) We start doing a lot of multiplications. However, as we don't have the actual shares yet, we just get deferreds. 3) Once the for-loop terminates, we return control to the surroundings. At this point we notice that the shares of x and y are there and start the actual multiplication protocols. Is my interpretation above correct? Because if it is, then this really explains the memory issues I've been seeing. And more importantly, it tells us how to actually use VIFF for large-scale computation: put in explicit "stops". As Mikkel wrote, I had the same issues and I solved them by calling parts of my code (one AES round at a time) as a callback of some trigger shares. ___ 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 large scale programs -- is VIFF really asynchronous?
Quoting t.t...@cwi.nl: Hi all, A really unpleasant thought has occurred to me: Is VIFF really properly asynchronous? (Yes, this question is intended to provoke you into thinking about the issue below. Of course VIFF is asynchronous in the sense that there are no rounds.) If I understand/remember correctly, VIFF is 100% single threaded. This means that if we have a small program: x, y = runtime.shamir_share([1, 2], Zp, input) z = x*y for i in xrange(100): z=z*z 1) We first share two values (returning immediately). 2) We start doing a lot of multiplications. However, as we don't have the actual shares yet, we just get deferreds. 3) Once the for-loop terminates, we return control to the surroundings. At this point we notice that the shares of x and y are there and start the actual multiplication protocols. Is my interpretation above correct? Because if it is, then this really explains the memory issues I've been seeing. And more importantly, it tells us how to actually use VIFF for large-scale computation: put in explicit "stops". Yes, that is how it works. Martin tells me that putting in "stops" is indeed the way to handle it, and apparently Marcel has done this successfully. However, I don't see how this makes VIFF less asynchronous. We are forcing it to synchronize to avoid some memory usage, but that in itself does not make it synchronous. The problem is that new python objects are created in each iteration of the loop, but the program does not try to get rid of any of the old ones by actually processing them. With 100 iterations, this is not a big deal, but if this is replaced by 1 or 100 (which is not unreasonable), it really becomes a problem. Indeed. I suppose that is the cost of handling it with deferreds, although I can imagine that other ways of implementing it would also run into problems if you carefully scheduled enough multiplications that depend on each other. ___ viff-devel mailing list (http://viff.dk/) viff-devel@viff.dk http://lists.viff.dk/listinfo.cgi/viff-devel-viff.dk
Re: [viff-devel] Yet another SFDL parser
I don't care which parser is used -- I just played around with it to learn more about Pyparsing. However, regardless of the choice, we should discuss who will commit to take the lead on it. We should have probably talked about that before we made 3 of them. I think we did agree on me, but somehow Sigurd and I ended up doing more or less the same thing concurrently. It would be great if you could go forward with the compiler! In Amsterdam we were asked about how long it would take, and I didn't have a good answer. Can you try to give a time estimate that we can tell the FairPlay guys? It's kind of hard to tell how long it will take, but I have a gut feeling that says that the basic functionality could be implemented very quickly (a matter of a few days concentrated effort at most), of course excluding the obligatory polishing phase which always takes forever. I can and will do this on the condition that we agree 100% that we don't do things in parallel :) However, we talked about this loss of momentum earlier. Up until Christmas, I am still teaching 2 classes and I think it would be a mistake for me to promise anything until January. Since ANTLR doesn't make it easy for us to to handle these "int " things, let's just use the parser you made. ___ viff-devel mailing list (http://viff.dk/) viff-devel@viff.dk http://lists.viff.dk/listinfo.cgi/viff-devel-viff.dk
Re: [viff-devel] Yet another SFDL parser
Quoting Martin Geisler <[EMAIL PROTECTED]>: Hi everybody, I've just sent 22 patches to the viff-patches list: http://thread.gmane.org/gmane.comp.cryptography.viff.patches/104 They represent yet another attempt at making a SFDL parser. I say "yet another" since Mikkel and Sigurd has been working on one too, but unfortunately that seems to have lost some momentum. Or at least I haven't heard anything about it recently :-) We haven't lost any momentum on the parser. In fact it has been done for quite a while. We have, however, lost momentum on the rest of the compiler. At the WP4 meeting in Amsterdam we talked about comparing VIFF to FairPlay on the same inputs, so we should move forward with building the converter. I don't care which parser is used -- I just played around with it to learn more about Pyparsing. However, regardless of the choice, we should discuss who will commit to take the lead on it. We should have probably talked about that before we made 3 of them. I think we did agree on me, but somehow Sigurd and I ended up doing more or less the same thing concurrently. ___ viff-devel mailing list (http://viff.dk/) viff-devel@viff.dk http://lists.viff.dk/listinfo.cgi/viff-devel-viff.dk
Re: [viff-devel] Fwd: error while installing viff
Apparently our mail system considers my test program a possible "security hazard", and I'm not really sure it got through ok. You can find it on http://tracker.viff.dk/issue48 ___ viff-devel mailing list (http://viff.dk/) viff-devel@viff.dk http://lists.viff.dk/listinfo.cgi/viff-devel-viff.dk
Re: [viff-devel] Fwd: error while installing viff
WARNING: This e-mail has been altered by MIMEDefang. Following this paragraph are indications of the actual changes made. For more information about your site's MIMEDefang policy, contact NFIT virus/spamfilter <[EMAIL PROTECTED]>. For more information about MIMEDefang, see: http://www.roaringpenguin.com/mimedefang/enduser.php3 An attachment named testmillionaires.bat was removed from this document as it constituted a security hazard. If you require this document, please contact the sender and arrange an alternate means of receiving it. Quoting Amitabh Saxena <[EMAIL PROTECTED]>: > Hi Martin, > > Sorry for the delayed reply. I've had partial success with viff. I tried on > a Vista box and an XP virtual machine. With Vista, I could not get the test > to run correctly. With the XP, I was able to install it but the test > millionaire program does not terminate (i.e., the programs say "I am > millionaire #1 and I have 10 millions", etc and do not do anything after > that). It seems there's some problem with communication in the VM. > > I think to install it properly, I need XP (not VM) or linux. I am planning > to install one of these soon. I'll let you know the results. Hi, I am running it perfectly on both XP and Vista with SSL turned OFF. However, there is currently a problem that makes SSL report the unclean closure of the connection on Windows XP (but everything does in fact work as it should), but on Vista, VIFF with SSL enabled does currently not work. If you are on Vista, you should run VIFF with --no-ssl (we hope to fix it soon). So far I have not made it hang yet, so I am a bit puzzled about that. Perhaps it has to do with the virtual machine, I don't know. I can come with a few suggestions as to what could have gone wrong: 1. Something went wrong with the installation (generic, I know). 2. You have the wrong config files for your players. 3. You have the wrong version of OpenSSL installed (that should report an error though). 4. Vista's built-in firewall blocks VIFF by default. Maybe it has not been set to allow it through yet. 5. You need to defragment your hard drive. This one is a joke :) 6. There is an undiscovered bug in VIFF (unspeakable!). I have attached a cute little test program which I have tested on both Vista and XP. Makes it easier to test it (don't worry, I am a trusted third party :)). Let us know what happens. We'd love for VIFF to work on all the major platforms, not just Linux. ___ viff-devel mailing list (http://viff.dk/) viff-devel@viff.dk http://lists.viff.dk/listinfo.cgi/viff-devel-viff.dk
[viff-devel] [issue70] Handle malformed messages
New submission from Mikkel Krøigård <[EMAIL PROTECTED]>: We provide active security protocols, but we cannot handle malformed messages. For example, it is not clear what to do if the string we are about to unmarshal is empty. -- keyword: active-security messages: 260 nosy: mk status: unread title: Handle malformed messages type: wish VIFF Issue Tracker <[EMAIL PROTECTED]> <http://tracker.viff.dk/issue70> ___ viff-devel mailing list (http://viff.dk/) viff-devel@viff.dk http://lists.viff.dk/listinfo.cgi/viff-devel-viff.dk
Re: [viff-devel] FW: Bug in ViFF
> My idea is that we should have unit tests which target one thing only: > The tests using BinaryOperatorTestCase targets coercion between plain > integers, field elements, and Share objects. The tests in > test_thresholds.py target different thresholds. You mean the multiplication test for example should only target coercion? Isn't that a bit strange? We have the share-share test for example, that's not really about coercion is it. I am not sure I agree with that way of doing it anyway. It seems to me that the thresholds test would have to test everything anyway, so to me it makes more sense that everything else can be tested with different numbers of players and different thresholds. ___ viff-devel mailing list (http://viff.dk/) viff-devel@viff.dk http://lists.viff.dk/listinfo.cgi/viff-devel-viff.dk
Re: [viff-devel] FW: Bug in ViFF
> Tomas is right, of course. For the passive case, using the first 2t+1 players > always works, and for the active case, we do not use the > local-multiply-and-reshare method anyway. The thing is, I always just assumed that we always used the same set of shares, and it is kind of easy to miss if you just read quickly through it - it says what you expect. I guess that's why we all missed it until now. The unit tests should not be hardcoded to n=3, t=1 as they are now, because that's why we never found the problem in the first place. I can rewrite the unit tests to the general setting. It needs to be done. ___ viff-devel mailing list (http://viff.dk/) viff-devel@viff.dk http://lists.viff.dk/listinfo.cgi/viff-devel-viff.dk
Re: [viff-devel] [issue69] Ship small libraries with VIFF
> New submission from Martin Geisler <[EMAIL PROTECTED]>: > > I think we could think about shipping the ConfigObj library directly > with VIFF. The ConfigObj library is self-contained in a single .py > file, and including it with VIFF would save people using Windows the > trouble of copying this file to their site-packages directory -- they > would not even have to know that they have such a directory... :-) Well they don't as it is, they are instructed by the installation instructions to run python setup.py install :) But after going through the installation process on another computer yesterday, I have to say it was a bit annoying. And I already knew how to do it, there's just a lot to do. Anything we can do to eliminate some of the steps... > Another small library which I would like to include is the decorator > library: > > http://pypi.python.org/pypi/decorator > > which is available as a zip-file only -- in the zip file there is a > single decorator.py file. Doesn't sound entirely necessary to zip that, but OK :) ___ viff-devel mailing list (http://viff.dk/) viff-devel@viff.dk http://lists.viff.dk/listinfo.cgi/viff-devel-viff.dk
Re: [viff-devel] What to benchmark
Citat Martin Geisler <[EMAIL PROTECTED]>: > I've looked at the GMPY code, and it is a fairly straightforward > wrapper for the GMP library, as you describe. > > But I don't know if it makes it easier for us to benchmark just > because it is split into its own C code... I never said it would. If you use this approach, it is easy to see how much is spent on the dangerous arithmetic, but I guess a profiler could tell you how much time Python spends on the functions implementing the operators anyway. It is not completely unimaginable, however, that someone would want to know how much actually goes on inside gmpy (arithmetic on big numbers, the data) and how much goes on outside (counting variables, various kinds of overhead). ___ viff-devel mailing list (http://viff.dk/) viff-devel@viff.dk http://lists.viff.dk/listinfo.cgi/viff-devel-viff.dk
Re: [viff-devel] Some profiling results
Citat Martin Geisler <[EMAIL PROTECTED]>: > Martin Geisler <[EMAIL PROTECTED]> writes: > > > Hi everybody, > > > > I have done some testing and come up with some strange numbers. I > > measured the time each individual multiplication takes by storing a > > timestamp when the multiplication is scheduled, and another when it > > finishes. > > Here is another plot which also shows when each multiplication is > started and how long it takes. > > I guess the first multiplication is so slow because you're busy scheduling the rest. Notice that no multiplication actually finishes until they have all been started. This diagram makes sense in my mind at least. ___ viff-devel mailing list (http://viff.dk/) viff-devel@viff.dk http://lists.viff.dk/listinfo.cgi/viff-devel-viff.dk
Re: [viff-devel] What to benchmark
Citat [EMAIL PROTECTED]: > I think there was earlier some version where arithmetic was done by calling > some > external C code. We are easily able to switch between gmpy (which is implemented in C) and Python arithmetic, if that's what you mean. I remember trying out how to implement Python modules in C, and you needed to define special functions that map to C functions. Presumably there is something of the same kind going on inside gmpy that we can measure separately from the rest of the Python code. I am not familiar with the profilers though, and I could be wrong. > Exercise: if you can measure 1) and 2), how do you measure 3)? :-) That's one tough equation. ___ viff-devel mailing list (http://viff.dk/) viff-devel@viff.dk http://lists.viff.dk/listinfo.cgi/viff-devel-viff.dk
Re: [viff-devel] Some profiling results
Citat Martin Geisler <[EMAIL PROTECTED]>: > In both plots we see that the first multiplication takes very long, it > is sort of waiting on the other multiplications. I think this is > because we're not yielding to the reactor when we start all the > multiplications. > > This also means that no network communication is started for the first > multiplication until after all multiplications have been scheduled -- > this is actually not what we want... > > Here are the plots, please let me know what you think of this. At a glance, it does look like the timing is being done correctly. Right now I can only confirm that there's definitely something funny going on in those plots. ___ viff-devel mailing list (http://viff.dk/) viff-devel@viff.dk http://lists.viff.dk/listinfo.cgi/viff-devel-viff.dk
Re: [viff-devel] What to benchmark
Actually upon reading my own email I realized that I forgot to mention the added bonus of having real internet communication going on if we have machines outside DAIMI involved in the testing. Martin, could you buy a dozen computers and set them up in various locations around the world? :) ___ viff-devel mailing list (http://viff.dk/) viff-devel@viff.dk http://lists.viff.dk/listinfo.cgi/viff-devel-viff.dk
Re: [viff-devel] What to benchmark
Citat Martin Geisler <[EMAIL PROTECTED]>: > I have already made a script which uses SSH to start any number of > playes here on DAIMI, and I've used it to test up to 25 players (it > took 15 ms on average for a 32-bit passively secure multiplication, > and 19 ms for an actively secure one). It should be fairly easy to > extend this to run nightly and make graphs from the results. > > Please come with your other good ideas -- or let us know why the above > are bad ideas! :-) Well I can't say there's anything wrong with the ideas about benchmarking, although I don't know the best way to separate the bookkeeping and the actual computations. With regards to the quoted bit above, if we're going to do such a thing, we should ask definitely ask the staff here at DAIMI for permission. Not only could they put a quick stop to it if they got annoyed, but it also seems likely that something's going to happen to some of the machines involved which will mess with our results. We should really have a (perhaps smaller) set of stable and otherwise unused machines for this sort of testing. Can we do this entirely outside DAIMI? ___ viff-devel mailing list (http://viff.dk/) viff-devel@viff.dk http://lists.viff.dk/listinfo.cgi/viff-devel-viff.dk
Re: [viff-devel] PRSS zero- and double-sharings
> > Well, there are many more or less interesting conclusions to draw > > from your benchmark, Martin. Not surprisingly, matrix multiplication > > turns out to be expensive. > > Hmm... I did see that there were a bunch of calls to __mul__ in > matrix.py, but I thought they came from the initialization of _hyper > in ActiveRuntime. The the initialization of _hyper does not use any > matrix multiplications, so this is wrong?! No the initialization of hyper should definitely not use matrix multiplications. > When the mul method uses prss_get_triple, then _hyper should never be > used or even initialized and so there should be no matrix stuff going > on... I think I measured the wrong code somehow :-) Well somehow, matrices were multiplied. And not only that, a lot of time was spent doing it :) > > One thing I really do find interesting about the table is the amount > > of time spent in inc_pc_wrapper. Perhaps it is possible to improve > > this somehow? > > It only used 0.5 seconds of its own time -- the 21 seconds are the > total time spend in the child-calls made by inc_pc_wrapper. Since it > wraps all important functions its clear that the cumulative time will > be big: > >ncalls tottime percall cumtime percall >48003/60030.5180.000 21.1950.004 > > But any optimization would be good -- if we can same a tiny bit for > each of the 48000 calls it might sum up :-) My observation was just that wrapping is somewhat expensive. I do not quite know what to do about this. We have already discussed the alternatives to using this method, and they were not particularly promising. ___ viff-devel mailing list (http://viff.dk/) viff-devel@viff.dk http://lists.viff.dk/listinfo.cgi/viff-devel-viff.dk
Re: [viff-devel] PRSS zero- and double-sharings
Well, there are many more or less interesting conclusions to draw from your benchmark, Marting. Not surprisingly, matrix multiplication turns out to be expensive. It is worth considering using a non-naive algorithm for this multiplication, but I am not convinced there is very much to gain. One thing I really do find interesting about the table is the amount of time spent in inc_pc_wrapper. Perhaps it is possible to improve this somehow? ___ viff-devel mailing list (http://viff.dk/) viff-devel@viff.dk http://lists.viff.dk/listinfo.cgi/viff-devel-viff.dk
Re: [viff-devel] Mailing list admins wanted
> Hello everybody, > > As you all know, I have just created two new mailing lists. Who want > to help administer them? > > This involves going to a Mailman page once in a while and basically > clicking a 'Delete everything' button to delete the spam. I can do that. I shall have to read the manual first, but it sounds like something even I can manage. ___ viff-devel mailing list (http://viff.dk/) viff-devel@viff.dk http://lists.viff.dk/listinfo.cgi/viff-devel-viff.dk
Re: [viff-devel] Mailing list for patches
> Hello everybody! > > I would like to propose that we create a new mailing list called > viff-patches where people can, well..., send their patches for VIFF. > > The idea would be to avoid flooding this list with patches which I > suspect many of you wont bother reading anyway. I will then integrate > patches posted on viff-patches after we have worked out any problems > in them -- I think some amount of code review is important and it > should be done by more people than just me. I think this is a very good idea. The ones of us who have already worked on the code should probably be on the new mailing lists, and people who are not looking at the code anyway don't really need to see all the patches. ___ viff-devel mailing list (http://viff.dk/) viff-devel@viff.dk http://lists.viff.dk/listinfo.cgi/viff-devel-viff.dk
Re: [viff-devel] Next release: VIFF 0.6
> Martin Geisler <[EMAIL PROTECTED]> writes: > > > [...] the zipfiles and tarballs now look like this: > > > > viff-x.y/ > > viff-x.y/doc/ <-- source files for documentation > > viff-x.y/doc/api/ <-- epydoc API documentation > > viff-x.y/doc/html/<-- Sphinx HTML files > > viff-x.y/apps/ > > viff-x.y/viff/ > > viff-x.y/viff/test/ > > I have now copied the documentation from the viff.dk repository to the > viff repository -- it is currently being built by the buildbot: > > http://buildbot.viff.dk/builders/Docs/builds/119 > > and will eventually appear here: > > http://viff.dk/builds/119/html/ > > Please check it out! > Just did. Out of curiosity... Anyone can stop the build by typing in a random name and reason? I didn't test this for obvious reasons. ___ viff-devel mailing list (http://viff.dk/) viff-devel@viff.dk http://lists.viff.dk/listinfo.cgi/viff-devel-viff.dk
Re: [viff-devel] Deferred overhead
> But to this we must add quite a lot of overhead as explained here: > > http://groups.google.dk/group/comp.lang.python/msg/4e0f9800c5898334 > > Using the heuristic there, an integer takes up 32 bytes and an empty > list takes up 40 bytes! Ugh... Well that is a lot of space for simple data types. I also found the following lines interesting: # Round to nearest multiple of 8 bytes x = size % 8 if x != 0: size += 8-x size = (size + 8) Say size is 20 (as in the case of an integer). Then x is 4. We do the rest and size becomes 32, which is not the nearest multiple of 8 bytes. Someone want to explain this to me? :) Anyone interested in this should probably read the source http://mail.python.org/pipermail/python-list/2002-March/135223.html which I think does a better job of explaining it. ___ 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: Try importing gnutls without introducing an unused binding.
> http://hg.viff.dk/viff/rev/19b875e0d65d > changeset: 685:19b875e0d65d > user: Martin Geisler <[EMAIL PROTECTED]> > date: Fri Apr 25 11:54:29 2008 +0200 > summary: Try importing gnutls without introducing an unused binding. > Just tested this in Windows. You no longer have to write --no-tls, it gets disabled by default. ___ viff-devel mailing list (http://viff.dk/) viff-devel@viff.dk http://lists.viff.dk/listinfo.cgi/viff-devel-viff.dk
[viff-devel] [issue32] double_share_random does not verify sharings
New submission from Mikkel Krøigård <[EMAIL PROTECTED]>: double_share_random is not fully implemented yet. It lacks the verification step, as pointed out by the TODO comment in the code. -- assignedto: mk keyword: active-security messages: 68 nosy: mg, mk priority: bug status: unread title: double_share_random does not verify sharings VIFF Issue Tracker <[EMAIL PROTECTED]> <http://tracker.viff.dk/issue32> ___ viff-devel mailing list (http://viff.dk/) viff-devel@viff.dk http://lists.viff.dk/listinfo.cgi/viff-devel-viff.dk
[viff-devel] [issue3] Support preprocessing
New submission from Mikkel Krøigård <[EMAIL PROTECTED]>: With the use of deferreds, some amount of preprocessing is already being done before the protocol begins proper. But this kind of preprocessing does nothing for the double auction case where the program branches during execution. So a general mechanism is needed by which one can preprocess a given number of multiplications, comparisons, etc. A possible design could be one in which this is done dynamically: when a protocol is executed, preprocessed stuff is taken from a pool as needed. If the pool runs dry, then more stuff is generated online. At the end of a run, the program will know how much stuff was needed -- this information can then be dumped to a file. A separate preprocessing script can read this information from the file and produce another file with a pickled pool of preprocessed stuff. -- keyword: design messages: 3 nosy: mk priority: feature status: unread title: Support preprocessing VIFF Issue Tracker <[EMAIL PROTECTED]> <http://tracker.viff.dk/issue3> ___ viff-devel mailing list (http://viff.dk/) viff-devel@viff.dk http://lists.viff.dk/listinfo.cgi/viff-devel-viff.dk
[viff-devel] [issue2] Define a hierarchy for Runtime functionality
New submission from Mikkel Krøigård <[EMAIL PROTECTED]>: The Runtime class keeps growing as more and more functionality is put into it. An option would be to split it into a basic Runtime which provides communication and nothing else. More functionality could be provided by mix-in classes. See the discussion here: http://thread.gmane.org/gmane.comp.cryptography.viff.devel/61/ -- keyword: design messages: 2 nosy: mk priority: wish status: unread title: Define a hierarchy for Runtime functionality VIFF Issue Tracker <[EMAIL PROTECTED]> <http://tracker.viff.dk/issue2> ___ viff-devel mailing list (http://viff.dk/) viff-devel@viff.dk http://lists.viff.dk/listinfo.cgi/viff-devel-viff.dk
Re: [viff-devel] Where to put the documentation?
> It would definitely be better to have an online HTML file. I think we > should replace the the INSTALL file with a simple one like that: > > Installation Instructions > == > > Please see http://viff.dk/installation.html > > What do people think of a scheme like this? Is it okay to ship the > releases with pointers to the web documentation? The solution seems very simple to me. Include instructions both on the download page and in the INSTALL file. ___ viff-devel mailing list (http://viff.dk/) viff-devel@viff.dk http://lists.viff.dk/listinfo.cgi/viff-devel-viff.dk
Re: [viff-devel] Asymmetric Bracha broadcast
> > if runtime.id == 1: > > a = runtime.broadcast(1, "foo") > > b = runtime.broadcast(2) > > if runtime.id == 2: > > a = runtime.broadcast(1) > > b = runtime.broadcast(2, "bar") > > if runtime.id == 3: > > a = runtime.broadcast(1) > > b = runtime.broadcast(2) > > > > This does not match the shamir_share method, which allows you to write > > > > a, b = runtime.shamir_share([1, 2], input) > > > > where input is different for each of the two inputters. > > That code is actually wrong, the correct code would be: > > if runtime.id == 1 or runtime.id == 2: > a, b = runtime.shamir_share([1, 2], input) > else: > a, b = runtime.shamir_share([1, 2]) This code assumes that the input is already determined above based on whether we have id 1 or 2. So there is somehow the same branch as in the broadcast case, only hidden here. ___ viff-devel mailing list (http://viff.dk/) viff-devel@viff.dk http://lists.viff.dk/listinfo.cgi/viff-devel-viff.dk
Re: [viff-devel] Self-extracting Windows archive
> http://viff.dk/tmp/viff-0.3.win32.exe > > The manual describes it as a self-extracting zip archive, so I assume > that it simply contains the .py files. Would somebody who runs Windows > please try it out and report back what happens? > > If it better than the normal zip file I made for the 0.3 release, then > we should definitely start making these exe files when releasing. > I have just installed it and run the benchmark test on Windows XP (without TLS), and it works fine. However, with the effort it takes to install the rest of what is needed for VIFF, I do not think it really makes it much easier with an installer just for VIFF because you already have to know where the files are supposed to go anyway (at least ConfigObj has to be placed manually as far as I could tell). If you really wanted to make it friendly, the installer would simply install everything needed. On the other hand, it is still quicker and more convenient to use the installer, so I would suggest releasing this VIFF for Windows in this format in the future along with a ZIP-file as well. -- 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
