http://permalink.gmane.org/gmane.comp.cryptography.viff.devel hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://permalink.gmane.org/gmane.comp.cryptography.viff.devel/525 Yes, that is how it works. Right, that is already there. Ah, that is very simple :-) Martin Geisler 2008-12-01T12:39:55 http://permalink.gmane.org/gmane.comp.cryptography.viff.devel/524 Folks, If the Paillier runtime is specifically designed for two parties, then I think there are easier ways to fill in the missing stuff than to use a variant of prss. More specifically, I believe the basic sharing method in the Paillier case is additive sharing, mod n, I guess, where n is the modulus - right? So if you want to share random unknown value, it's dead easy: A and B choose a random value mod n each, say xA and xB and we define that the shared value is x= xA +xB mod n. Sharing a random unknown binary value is a bit harder, because the standard trick where we square and open a random value will not work here: we cannot compute square roots mod n efficiently, not even in public. But for two parties and passive security, it's not soo bad: we can just let A and B choose bits bA, bB and compute the XOR in shared form: A chooses bA and B uses 0 as his share of bA (and vice versa for bB). Now, with b= bA XOR bB, we just use the standard formula [b] = [bA] + [bB] - 2[bAbB] Fo Ivan Bjerre Damgård 2008-12-01T10:13:05 http://permalink.gmane.org/gmane.comp.cryptography.viff.devel/523 Good evening, I've been doing some more performance measurements. This time I replaced the shamir.share and shamir.recombine functions with fake versions (see revision f7d1f7cd3dda). The replacements do a zero-degree sharing: [(1, 17), (2, 17), (3, 17)] 17 They skip the normal machinery and do: share = lambda s, t, n: [(s.field(i+1), s) for i in range(n)] recombine = lambda s, x=0: s[0][1] Enabling both fakes gives these timing results when doing 10000 multiplications on camel{10..12} on DAIMI (thyra02 is down so I used the slightly slower camel machines): +-------------------+----------+----------+------+ | Field size (bits) | Real (s) | Fake (s) | Diff | +-------------------+----------+----------+------+ | 50 | 14.3 | 11.5 | 20% | +-------------------+----------+----------+------+ | 100 | 14.4 | 11.4 | 21% | +-------------------+----------+----------+------+ | 200 | 14.6 | 11.7 | 20% | + Martin Geisler 2008-11-30T22:44:52 http://permalink.gmane.org/gmane.comp.cryptography.viff.devel/522 Martin Geisler 2008-11-30T17:30:47 http://permalink.gmane.org/gmane.comp.cryptography.viff.devel/521 Ah, nice! I didn't expect this :-) the help. Martin Geisler 2008-11-18T08:25:59 http://permalink.gmane.org/gmane.comp.cryptography.viff.devel/520 Martin Geisler schrieb: If the crypt use flag is enabled, pyOpenSSL is a dependency of twisted. One could also install pyOpenSSL directly (emerge pyopenssl), but that will be broken if twisted changes its SSL library. On the other hand, the use flag could also change. Marcel Keller 2008-11-17T16:18:48 http://permalink.gmane.org/gmane.comp.cryptography.viff.devel/519 Martin Geisler 2008-11-17T15:46:09 http://permalink.gmane.org/gmane.comp.cryptography.viff.devel/518 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. Marcel Keller 2008-11-17T12:54:55 http://permalink.gmane.org/gmane.comp.cryptography.viff.devel/517 Hi everybody, I have been looking at writing a specification of "VIFF as a VM". The idea is to consider the API offered by VIFF as a target for a compiler (not yet written). This is done for the CACE project[1] where there will be a meeting on December 3rd. So far I've made a rough sketch of such a specification, and I would like your comments. I've attached a PDF with the latest version (I'm sorry that this file got so big, but someone managed to make a 1.4 MiB file with the CACE logo, and this is included in the PDF.). Currently I have written a bit about this and that, but the document need some heavy editing. You can find my work here: http://www.bitbucket.org/mg/viff-spec/overview/ http://www.bitbucket.org/mg/viff-spec/get/tip.zip and you are very welcome to send me any corrections. [1]: CACE homepage: http://www.cace-project.eu/ Martin Geisler 2008-11-17T10:22:25 http://permalink.gmane.org/gmane.comp.cryptography.viff.devel/516 Yes, that is a good idea -- I'll try to rip out the Shamir sharing and recombination next. Then we can gradually strip things down to the bare "machinery" behind it all. Martin Geisler 2008-11-06T19:16:53 http://permalink.gmane.org/gmane.comp.cryptography.viff.devel/515 Hi folks, Very interesting! I think Martin is right that there is something lost in general machinery, but I don't think this means that none of this machinery can be removed. There are bigger lumps of computation that could be done with one call to a faster module. Examples: 1) Lagrange interpolation, i.e., reconstructing secret from a set of shares 2) the linear recombination that is done at the end of a multiplication. 3) Secret sharing, i.e., given secret, choose random polynomial and evaluate in given points 4) PRSS, which also involves some symmetric crypto. I guess it would be easy to simply skip 2) in the current code, simulating that we have a superfast for linear combination, and see what difference that makes.. regards, Ivan Quoting Martin Geisler <mg< at >daimi.au.dk>: Ivan Bjerre Damgård 2008-11-06T15:07:17 http://permalink.gmane.org/gmane.comp.cryptography.viff.devel/514 Hi everybody, I've done some tests where I replaced the normal FieldElement class with a new class named FakeFieldElement (rev 464008ada9c2). This class fakes all computations by always returning 1. Timing 10000 multiplications using the real and the fake field elements give these results between three machines on the DAIMI LAN: +-------------------+----------+----------+------+ | Field size (bits) | Real (s) | Fake (s) | Diff | +-------------------+----------+----------+------+ | 50 | 14.1 | 13.5 | 4% | +-------------------+----------+----------+------+ | 100 | 14.3 | 13.2 | 8% | +-------------------+----------+----------+------+ | 200 | 14.5 | 13.3 | 8% | +-------------------+----------+----------+------+ | 400 | 15.0 | 13.1 | 13% | +-------------------+----------+----------+------+ | 800 | 16.2 | 13.3 | 18% | +-------------------+----------+----------+------+ Martin Geisler 2008-11-06T13:55:18 http://permalink.gmane.org/gmane.comp.cryptography.viff.devel/513 New submission from Thomas Pelle Jakobsen <mas< at >daimi.au.dk>: Would it be an idea to investigate how to include viff in the "universe" package repository for Debian/Ubuntu? Ideally, doing a apt-cache search viff would then install viff and all dependencies. This is how most Deb/Ubuntu users prefer to install things (at least, I think). ---------- importance: 8.0 messages: 294 nosy: mas status: unread title: Debian/Ubuntu installer type: wish ____________________________________ VIFF Issue Tracker <tracker< at >viff.dk> <http://tracker.viff.dk/issue78> ____________________________________ Thomas Pelle Jakobsen 2008-11-05T18:14:24 http://permalink.gmane.org/gmane.comp.cryptography.viff.devel/512 New submission from Martin Geisler <mg< at >daimi.au.dk>: This is an idea which I think Thomas came up with first: it would be very nice if one could limit the memory usage to, say, 200 MiB. The program should run a normal, but when the memory usage grows above the limit, the remaining parts of the program should be delayed. When memory has been released, the program starts again. There are two problems with this: * Is it safe? * How should it work? The first question is a matter of avoiding deadlocks. The Deferreds used in VIFF can depend on other Deferreds, and we want to avoid cycles in the dependency graph. Locally I think it is okay since we always make the Deferreds wait on each other, and ultimately wait on incoming network traffic. So that should work. Globally is a different matter: can P1 be in a situation where it needs data from P2, and P2 needs data from P1? I don't hope so :-) As for how this could be implemented in an as seamless way as possible, then I just got an idea! It is too late t Martin Geisler 2008-11-05T14:20:05 http://permalink.gmane.org/gmane.comp.cryptography.viff.devel/511 New submission from Martin Geisler <mg< at >daimi.au.dk>: I think it would be interesting to log the use of the CPU, the network, and the memory throughout a protocol run. Getting CPU and memory data is probably just a matter of reading the correct file under /proc (good luck finding that, Windows users...). For measuring the network usage we could keep track of the number of bytes sent and received and so get more details than just the current bandwidth used (which I wouldn't know how to get anyway). ---------- assignedto: mg messages: 292 nosy: mg status: unread title: Log CPU, mem and net utilization type: wish ____________________________________ VIFF Issue Tracker <tracker< at >viff.dk> <http://tracker.viff.dk/issue76> ____________________________________ Martin Geisler 2008-11-05T13:51:29 http://permalink.gmane.org/gmane.comp.cryptography.viff.devel/510 New submission from Martin Geisler <mg< at >daimi.au.dk>: We want to do tests where all local computations are replaced by dummy implementations. An example would be the multiplications of field elements done in viff.field. Having timing results from such a dummy implementation would give us a baseline. Comparing this to the normal timings should tell us how much we can hope to save by using faster routines from the NaCl library. ---------- assignedto: mg messages: 290 nosy: mg status: unread title: Test without local computations type: wish ____________________________________ VIFF Issue Tracker <tracker< at >viff.dk> <http://tracker.viff.dk/issue75> ____________________________________ Martin Geisler 2008-11-05T13:45:31 http://permalink.gmane.org/gmane.comp.cryptography.viff.devel/509 New submission from Martin Geisler <mg< at >daimi.au.dk>: It should be possible to test a single player in isolation by replaying old network communication. That would allow us to measure the time spent on local computations and the overhead from the whole Twisted machinery. ---------- assignedto: mg messages: 289 nosy: mg status: unread title: Test without network communication type: wish ____________________________________ VIFF Issue Tracker <tracker< at >viff.dk> <http://tracker.viff.dk/issue74> ____________________________________ Martin Geisler 2008-11-05T13:43:15 http://permalink.gmane.org/gmane.comp.cryptography.viff.devel/508 New submission from Martin Geisler <mg< at >daimi.au.dk>: Python allows a class to list its attributes in a special __slots__ attribute. This saves allocating memory for the dictionary which normally holds the class' attributes. ---------- assignedto: mg keyword: design messages: 288 nosy: mg status: unread title: Investigate use of __slots__ type: wish ____________________________________ VIFF Issue Tracker <tracker< at >viff.dk> <http://tracker.viff.dk/issue73> ____________________________________ Martin Geisler 2008-11-05T13:40:37 http://permalink.gmane.org/gmane.comp.cryptography.viff.devel/507 Hi everybody, I would just like to draw attention to a recent ePrint report on VIFF: http://eprint.iacr.org/2008/415 It gives a formal description of the asynchronous protocol used against active adversaries in VIFF and some benchmark results. Martin Geisler 2008-10-27T08:43:41 http://permalink.gmane.org/gmane.comp.cryptography.viff.devel/506 Hi everybody, We have something to celebrate -- we've got 1001 changesets in the main VIFF repository: http://hg.viff.dk/viff/ If we take a look at the number of lines changed per month we can see how the intensity has gone up and down over the last year and a half: % hg churn -f '%Y-%m' -s 2007-06 4802 ************************************ 2007-07 2409 ****************** 2007-08 2806 ********************* 2007-09 2407 ****************** 2007-10 7341 ******************************************************** 2007-11 1390 ********** 2007-12 4292 ******************************** 2008-01 126 2008-02 2322 ***************** 2008-03 5579 ****************************************** 2008-04 5340 **************************************** 2008-05 1425 ********** 2008-06 56 2008-07 1425 ********** 2008-08 606 **** 2008-09 2351 ***************** 2008-10 3292 ************************* Here I would say that the drop in January corresponds to me Martin Geisler 2008-10-15T07:12:46 http://permalink.gmane.org/gmane.comp.cryptography.viff.devel/505 Martin Geisler 2008-10-13T12:35:02 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.comp.cryptography.viff.devel