[viff-devel] Viff installation on Gentoo

As requested, here is the command to install the dependencies on Gentoo: $ emerge -av twisted gmpy Make sure to have the crypt use flag enabled, otherwise SSL might not be available. ___ viff-devel mailing list (http://viff.dk/) viff-devel@viff.dk ht

Re: [viff-devel] Viff installation on Gentoo

Martin Geisler schrieb: Marcel Keller <[EMAIL PROTECTED]> writes: As requested, here is the command to install the dependencies on Gentoo: $ emerge -av twisted gmpy Make sure to have the crypt use flag enabled, otherwise SSL might not be available. Thank you very much! I have include

[viff-devel] ComparisonToft07Mixin

Hi Does anyone know of a documentation explaining the code in the ComparisonToft07Mixin class in comparison.py? I've read the relevant part of Tomas' dissertation but it seems that the algorithm there is different. Best regards, Marcel ___ viff-dev

Re: [viff-devel] VIFF and large scale programs -- is VIFF really asynchronous?

> 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 i

[viff-devel] Multi-party AES encryption

Hi, VIFF now supports AES encryption (but not decryption). You find it in the repository http://hg.viff.dk/mkeller. There is an example application in the apps directory. Best regards, Marcel ___ viff-devel mailing list (http://viff.dk/) viff-devel@

Re: [viff-devel] Multiparty AES in less than 3 seconds per block thanks to Twisted hack

Hi Ivan, > For instance, you call what you did a hack - is there a more "official" way to do it? I call it a hack because of two reasons: - The maintainer of Twisted doesn't want to implement something similar upstream. - It breaks some unit tests. I'm not sure whether it really breaks funct

[viff-devel] Mystery of the quadratic running time solved?

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):

Re: [viff-devel] Mystery of the quadratic running time solved?

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 ou

Re: [viff-devel] Mystery of the quadratic running time solved?

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 reac

Re: [viff-devel] Mystery of the quadratic running time solved?

Wow, this is nice! I had sort of given up finding the cause of this :-( Thank you for looking at this, and just in time for my presentation at PKC in 10 days :-) You're welcome. :-) --- /usr/lib/python2.5/site-packages/twisted/internet/base.py 2008-07-29 22:13:54.0 +0200 +++ interne

Re: [viff-devel] Mystery of the quadratic running time solved?

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 fu

Re: [viff-devel] Multiparty AES in less than 3 seconds per block thanks to Twisted hack

For those who are not on the Twisted mailing list, the reply is here: http://twistedmatrix.com/pipermail/twisted-python/2009-February/019252.html There Jean-Paul Calderone says that he doesn't believe in a re-entrent reactor, but he does not explain in detail why that it so. I think there ar

Re: [viff-devel] Mystery of the quadratic running time solved?

You're talking about this two-threaded solution as if it is something that exists and will solve all our problems... No, for now, it's just an imagination in my mind, a proposal for the next meeting, and a strong feeling that it's the right way to do it. But I still haven't seen it, and I wo

Re: [viff-devel] Mystery of the quadratic running time solved?

I think we would get the same result if we started a LoopingCall that executes process_deferred_queue with an interval of, say, 100 ms: http://twistedmatrix.com/documents/8.2.0/api/twisted.internet.task.LoopingCall.html This should work since the runUntilCurrent method runs through the waitin

Re: [viff-devel] Mystery of the quadratic running time solved?

Hi Ivan, I just wanted to say that I think it would be great if you would implement a version of your proposed two-threaded solution. I do not have a firm grasp of all the programming details, but it does seem that the overall idea is converging, and that some time soon the best way to judge

Re: [viff-devel] Confusing behaviour?

I think the problem is the following: Every players sends its id on a new connection, and the connection is considered to be set up when this id arrives. So it may occur that a player has received the ids from all other players and wants to send its id to other player(s). But nothing is sent be

[viff-devel] Two-threaded VIFF

Hi friends of VIFF, I've finally completed the patch for a two-threaded VIFF where most of the VIFF code runs in a separate thread. The patch is against the tip of my repository: http://hg.viff.dk/mkeller It turned out be not so straight-forward as I thought. I had to use a recursion, as in

[viff-devel] How to avoid the boring math

Hi friends of VIFF, I've now played a little bit with artificial bandwidth limits and artificial delays in order to be able to better analyze protocols. (Actually, my motivation was to get the running time for AES matching my analysis. It worked.) I found out that setting a delay of 1 second

[viff-devel] Non-default reactors

Hi friends of VIFF, Who is working with non-default reactors, such as gtk2reactor? How do you deal with the fact that VIFF might block the reactor for a long time which might render the GUI non-responsive? I'm currently working on a special reactor for VIFF to get more control over the sched

[viff-devel] Say hello to viff.reactor

Hi friends of VIFF, I've now implemented a special reactor for VIFF, based on the standard SelectReactor. The new reactor should make non-trivial programs considerably faster, e.g. computation of 10 AES-blocks in parallel from over 6 seconds to 2.3 seconds per block (3 players, passive securit

Re: [viff-devel] Broken unit tests

Hi Martin, Martin Geisler wrote: All the tests in the buildbot are currently broken: http://buildbot.viff.dk/waterfall It is because of this change of yours: @@ -164,6 +166,18 @@ # the Runtime, since we want everybody to wait until all # runtimes are ready. self.r

Re: [viff-devel] Broken unit tests

Martin Geisler wrote: I'm very confused about what exactly for x in xs[i:] + xs[:i]: ... i = (i + 1) % len(xs) is supposed to do? After x has run through all xs (rotated i steps), then i will have been incremented by len(xs). But you do it mod len(xs) and so i comes out of the loop un

[viff-devel] Optimizing preprocessing

Dear friends of VIFF, I have a proprosal to optimize preprocessing in VIFF, which I would like to put up for discussion. Notation: - D(x): a Deferred object whose callback function will be called with x - S(x): same for a Share object - F: a FieldElement object - [x, ...]: a Python list - (x,

Re: [viff-devel] Optimizing preprocessing

Hi Janus, I am not opposed to your suggestion. However I would like to point out that in VIFF you compute on shares and not field elements!. Computing directly on the field elements is hacking the abstractions of VIFF. I don't think so. Since I work with VIFF, it treats field elements as the

Re: [viff-devel] AES slides from SPEED-CC

Hi, There are two talks about how to implement AES efficiently, this one http://www.hyperelliptic.org/SPEED/slides09/kasper-aes_speedcc09_slides.pdf describes on slide 9 how one will typically combine SubBytes, ShiftRows, and MixColumns into one operation operating on diagonals. I don't know

Re: [viff-devel] Optimizing preprocessing

Martin Geisler wrote: Janus Dam Nielsen writes: Hi Marcel, I am not opposed to your suggestion. However I would like to point out that in VIFF you compute on shares and not field elements! Well, we've actually made the outer runtime interfaces in such a way that add, mul, xor, etc... accept

Re: [viff-devel] Optimizing preprocessing

Janus Dam Nielsen wrote: On 21/10/2009, at 20.28, Marcel Keller wrote: Martin Geisler wrote: Janus Dam Nielsen <mailto:janus.niel...@alexandra.dk>> writes: Hi Marcel, I am not opposed to your suggestion. However I would like to point out that in VIFF you compute on shares and

[viff-devel] Orlandi preprocessing

Hi Janus, I remember you saying today that the preprocessing in the OrlandiRuntime is more efficient per item the more items are requested. Is that correct? I ask because in my optimizations, I limited the items being preprocessed per call in order to save memory. I would of course drop that

[viff-devel] Noisy preprocessing

Hi Janus, do you still need the timing output in the update callback in Runtime.preprocess()? It makes benchmarking the usual runtimes very noisy because the update callback is called many times there. Best regards, Marcel ___ viff-devel mailing list

Re: [viff-devel] Noisy preprocessing

hould make it an option. On 28/10/2009, at 20.01, Marcel Keller wrote: Hi Janus, do you still need the timing output in the update callback in Runtime.preprocess()? It makes benchmarking the usual runtimes very noisy because the update callback is called many times there. Best regards, M

[viff-devel] OrlandiRuntime implementation

Hi Claudio and Jesper, In the code review of the OrlandiRuntime we found two points, we want to discuss with you. Step 3 of the triple generation protocol says: Coin-flip a subset \fancy_T \subset \fancy_M of size \lambda(2d + 1)M. The current implementation loops over the elements in \fancy

Re: [viff-devel] OrlandiRuntime implementation

Claudio Orlandi wrote: On Wed, Nov 4, 2009 at 5:46 AM, Marcel Keller wrote: Hi Claudio and Jesper, In the code review of the OrlandiRuntime we found two points, we want to discuss with you. Step 3 of the triple generation protocol says: Coin-flip a subset \fancy_T \subset \fancy_M of size

Re: [viff-devel] OrlandiRuntime implementation

Claudio Orlandi schrieb: On Wed, Nov 4, 2009 at 10:15 AM, Marcel Keller wrote: Claudio Orlandi wrote: On Wed, Nov 4, 2009 at 5:46 AM, Marcel Keller wrote: Hi Claudio and Jesper, In the code review of the OrlandiRuntime we found two points, we want to discuss with you. Step 3 of the triple

Re: [viff-devel] Equality protocol : error

Hi Jonathan, I can't reproduce the error here. Can you send me your config files? The error might be triggered by certain random numbers, which depend on the PRSS keys. By the way, the error message is about the same every time something goes wrong in a callback. This is because VIFF does no

Re: [viff-devel] Equality protocol : error

ar Mr. Keller, Here are the files compressed in a .zip files. It should be ok with the filter. Best regards, Jonathan Le 15 avr. 2010 à 13:36, Marcel Keller a écrit : Hi Jonathan, The spam filter of the university removed the attached config files. Were they in some ASCII format? Names like

Re: [viff-devel] A potential bug in the Shamir Module

Hi, The bug is this line: cur_point = secret.field(i) If the number of player exceed the size of the field then the function returns the wrong id (cur_point)? Shamir secret sharing only works if the field is strictly bigger than the number of players. Otherwise, there would not be en

Re: [viff-devel] VIFF reactor

Hi Joel, Is it still necessary to run `viff.reactor.install()` as described in 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 cha

Re: [viff-devel] Value overflow in Toft07

Dear Lars, thanks for pointing it out. It is now fixed in the official repository. Best regards, Marcel Lars Krapf wrote: Hello VIFF-team I would like to suggest the following patch to viff/comparison.py: 159c159 < l = int(self.options.security_parameter + math.log(dst_field.modulus

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 w

[viff-devel] Say hello to viff.boost

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. The code is in my repository: http://hg.viff.dk/mkeller To use the extension, first compile and inst

Re: [viff-devel] Say hello to viff.boost

same. Best regards, Marcel Marcel Keller wrote: 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. The code is in my repository: http://hg.vi