Re: [viff-devel] millionaires example does not work on three different machines

2010-09-27 Thread Sigurd Torkel Meldgaard
It might be because you are using the initfiles that are made for localhost

if I do:

[...@camel01:~/viff/apps]$ generate-config-files.py -n 3 camel01:9001
camel02:9002 camel03:9003
[...@camel01:~/viff/apps]$ generate-certificates.py player-1.ini
player-2.ini player-3.ini
[...@camel01:~/viff/apps]$ python millionaires.py player-1.ini

And on the other machines (with a shared homedir)

[...@camel02:~/viff/apps]$ python millionaires.py player-2.ini
[...@camel03:~/viff/apps]$ python millionaires.py player-3.ini

Everything seems to work fine.

Hope that helps

/Sigurd

On Mon, Sep 27, 2010 at 3:20 AM, Kyung-Wook Hwang
 wrote:
> Hello,
>
> My name is Kyung Hwang, a Ph.D. candidate at Columbia University.
>
> I set up and tried to test VIFF's millionaires example. It works great
> when I ran it on a single linux machine. However, it does not work on
> three different machines.
>
> I am quite sure that all the three machines were correctly configured
> and they were actually connected to one another when I ran
> millionaires.py because they waited for all the three machines to
> start VIFF, and after they were all connected, each of them resumed
> its process and printed out its input information, for example, as
> follows (for player-1): "I am Millionaire 1 and I am worth 19
> millions."
>
> However, that is it and it does not proceed any further, and it does
> not show the computation results which are supposed to be as follows:
>
> From poorest to richest:
>  Millionaire 1 (19 millions)
>  Millionaire 3
>  Millionaire 2
> Synchronizing shutdown... done.
> Closing connections... done.
> Stopping reactor... done.
>
>
> It looked to me that each of those three players was trying to do the
> computation (or comparison) and somehow it kept waiting for the other
> players' shares or responses..
>
> I looked at the bug report board, but I could not find related reports.
>
> Please take a look at this issue. I will look forward to hearing from you.
>
> Thank you.
>
> Kyung
> ___
> 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] Equality protocol : error

2010-04-10 Thread Sigurd Torkel Meldgaard
> Thank you for your idea wich is very helpful to me since I actually work with 
> p = 53.
> Using this is much more efficient !

Might I guess you are implementing a card game? ; )

- 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] Equality protocol : error

2010-04-08 Thread Sigurd Torkel Meldgaard
I know this is talking around the problem but:

For very small moduli like yours, another protocol for equality is
actually simpler, better (no risk of failing) and faster (I guess):

raise (a-b) to n-1 (with square and multiply), and if this difference
was 0 you will get 0, otherwise you will get 1 (good old fermat), this
result can be subtracted from 1, to turn the bit correctly.

I actually coded this once, but for some reason I never got to put it into Viff

I have attached a patch you can try to apply (use hg qimport
fermatequality, hg qpush), and play with for now.

I will try to look into the real bug later.

The best
Sigurd

On Thu, Apr 8, 2010 at 11:34 PM, Marcel Keller  wrote:
> 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 not define errbacks. To
> get a little bit more meaningful output, you can use the --deferred-debug
> parameter.
>
> Best regards,
> Marcel
>


fermatequality
Description: Binary data
___
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

2009-10-21 Thread Sigurd Torkel Meldgaard
> 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  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] Commit messages

2009-10-19 Thread Sigurd Torkel Meldgaard
On Mon, Oct 19, 2009 at 2:14 PM, Janus Dam Nielsen
 wrote:
> I like it.
> On 19/10/2009, at 13.55, Martin Geisler wrote:

Me too, and it should be documented by a line or two in the developer
guide-lines, so it can be looked up.

>
> Hi guys,
>
> I made a bunch of cleanup commits two days ago, and for those I used a
> new style for the commit messages:
>
>  : 
>
>  
>
> You can see it here:
>
>  http://hg.viff.dk/viff/
>
> I think it makes it easier to quickly see if a commit is related to the
> AES code, the Orlandi runtime, etc.
>
> Please let me know if you like it or not and if you think we should
> switch to this style from now on.
>
> --
> 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
>
> 
> 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
>
>
___
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

2009-08-25 Thread 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


Re: [viff-devel] Importing shares into VIFF

2009-03-25 Thread Sigurd Torkel Meldgaard
The simple_share_value needs to be converted to a field-element
(reduced modulo P)

m = Share(runtime, Zp, Zp(simple_share_value))

Should work

- Sigurd

On Wed, Mar 25, 2009 at 1:55 PM, Håvard Vegge  wrote:
> Hello!
>
> In my quest for using VIFF in a web application scenario, I have created
> three simple shares (positive integers) and stored them in a database. How
> do I import these shares into VIFF?
>
> m = Share(runtime, Zp, simple_share_value)
>
> I tried something like the code above, by I get a lot of errors, part of it
> saying:
> "self.sendData(program_counter, "share", share.value)
> exceptions.AttributeError: 'long' object has no attribute 'value'"
>
> So, what is wrong and how do I fix it?
> I've kind of solved it by using some of Tord's ninja tricks, but I think
> what I'm trying to do really is quite simple.
>
> Best regards, Håvard
> ___
> 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-devel Digest, Vol 17, Issue 12

2009-02-23 Thread Sigurd Torkel Meldgaard
> Hi! I'm experimenting with the RSA problem in VIFF, so i need to have
> 2 primes (p and q) plus d (the inverse) secret shared.

I Guess what you really want is the inverse operation modulo pq. What
I implemented is integer division (rounding down)

If you are allowed to reveal n=pq then the inverse of d can be
computed with a protocol like

[r] = random element
c = open(d[r])
k = c inverse mod n (if it exists, otherwise retry with new randomness)
return [r]k

Hope you can use that

Sigurd
___
viff-devel mailing list (http://viff.dk/)
viff-devel@viff.dk
http://lists.viff.dk/listinfo.cgi/viff-devel-viff.dk


[viff-devel] The best simulator for P2P-protocols

2008-12-27 Thread Sigurd Torkel Meldgaard
I just saw this on reddit - we might like to look into some of the
mentioned tools:

http://www.reddit.com/r/programming/comments/7lute/ask_proggit_what_is_the_best_simulator_for_p2p/
___
viff-devel mailing list (http://viff.dk/)
viff-devel@viff.dk
http://lists.viff.dk/listinfo.cgi/viff-devel-viff.dk


[viff-devel] Benchmarks on a mac

2008-12-10 Thread Sigurd Torkel Meldgaard
Here is a transcript of my profiling run.

I disabled ssl, because I had some trouble with the keys, hope that
does not matter too much.

sigurdmeldgaard$ python benchmark.py --profile --no-ssl -c 1 player-1.ini
Seeding random generator with random seed 9520
Using field elements (65 bit modulus)
I am player 1, will mul 1 numbers
Using the base runtime: viff.passive.PassiveRuntime.
Not using SSL
Listening on port 9000
Will connect to 
Will connect to 
 Starting reactor ###
Starting reactor with profiling
Need no preprocessing
Runtime ready, generating shares
Synchronizing test start.
Starting test in 3
Starting test in 2
Starting test in 1
Starting test now

Started parallel test

Total time used: 21.186 sec
Time per parallel test operation: 2 ms
**
Synchronizing shutdown...  done.
Closing connections...  done.
Stopping reactor...  done.
Loading profiling statistics... done.

 2176272 function calls (1852904 primitive calls) in 33.202 CPU seconds

   Ordered by: internal time, call count
   List reduced from 207 to 40 due to restriction <40>

   ncalls  tottime  percall  cumtime  percall filename:lineno(function)
  366   20.9230.057   26.6800.073 selectreactor.py:93(doSelect)
173360/866802.5240.0009.8540.000 defer.py:314(_runCallbacks)
90013   1.0700.0001.3150.000 field.py:371(__mul__)
  307   0.9710.0035.6750.018 basic.py:321(dataReceived)
6   0.7720.0000.9040.000 runtime.py:579(_expect_data)
16668   0.5550.0002.1890.000 shamir.py:30(share)
203364/933640.5180.0006.1410.000 defer.py:172(addCallbacks)
   260039   0.4780.0000.4780.000 field.py:339(__init__)
33340   0.3600.0000.8330.000 runtime.py:311(sendData)
20004   0.3480.0001.8110.000 runtime.py:189(__init__)
8   0.3370.0004.6550.000 runtime.py:272(stringReceived)
113350/433500.2970.0005.4900.000 defer.py:189(addCallback)
80004   0.2970.0000.4080.000 field.py:342(__add__)
6   0.2700.0001.3980.000 runtime.py:613(_expect_share)
70021/46678 0.2530.0004.3540.000 
defer.py:291(_startRunCallbacks)
1   0.2260.0000.6050.000 shamir.py:96(recombine)
33342   0.2040.0000.2900.000 abstract.py:161(write)
1   0.1870.0004.7900.000 passive.py:163(share_recombine)
70021/46678 0.1800.0004.4770.000 defer.py:233(callback)
70010   0.1740.0000.3630.000 runtime.py:66(__init__)
2   0.1670.0001.6700.000 passive.py:389(shamir_share)
80006/70004 0.1670.0001.3370.000 runtime.py:213(_callback_fired)
30002   0.1530.0007.9910.000 runtime.py:358(inc_pc_wrapper)
23336   0.1440.0000.1440.000 random.py:217(_randbelow)
23336   0.1420.0000.2860.000 random.py:147(randrange)
30006   0.1390.0001.8010.000 
runtime.py:597(_exchange_shares)
33342   0.1330.0000.4730.000 basic.py:338(sendString)
1   0.0880.0886.5056.505 benchmark.py:247(run_test)
1   0.0800.0006.1670.001 passive.py:138(mul)
1   0.0730.0732.2342.234 benchmark.py:197(begin)
20004   0.0660.0002.0600.000 runtime.py:221(gather_shares)
70020   0.0590.0000.0590.000 defer.py:166(__init__)
33346   0.0590.0000.0860.000 abstract.py:264(startWriting)
1   0.0580.0004.8490.000 
runtime.py:559(callback_wrapper)
6   0.0580.0000.1110.000 runtime.py:615()
1   0.0520.0005.1660.001 
runtime.py:539(schedule_callback)
33342   0.0510.0000.0510.000 struct.py:54(pack)
33628   0.0490.0000.0490.000 struct.py:77(unpack)
33340   0.0470.0000.8810.000 runtime.py:315(sendShare)
23336   0.0390.0000.3250.000 random.py:211(randint)
___
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

2008-09-24 Thread Sigurd Torkel Meldgaard
I have made a quick change of the field-implementation so that it uses
gmpy instead of internal longs, and it seems that for integers in the
interval we usually use (~64 bits) it actually runs a bit slower (a
equality test took 808 ms. instead of 767), I made a run with a modulo
with 300 bits, and gmpy showed some speedup (965 ms. against 1199
ms.).
All where tests done locally on camel12.

I attach the patch if you want to play with it - maybe there is a much
better way to do the interfacing.

Sigurd


gmpy
Description: Binary data
___
viff-devel mailing list (http://viff.dk/)
viff-devel@viff.dk
http://lists.viff.dk/listinfo.cgi/viff-devel-viff.dk


Re: [viff-devel] Small VIFF language parser

2008-07-11 Thread Sigurd Torkel Meldgaard
Hi everybody

I have just cloned the viff source, and am sitting impressed by the
details and the nice work. Thanks for giving me a hint of the projects
existence.  I will surely do my best to get involved and contribute.

Sigurd

On Thu, Jul 10, 2008 at 12:51 AM, Martin Geisler <[EMAIL PROTECTED]> wrote:
> Ivan Bjerre Damgaard <[EMAIL PROTECTED]> writes:
>
>> Quoting Martin Geisler <[EMAIL PROTECTED]>:
>>
>>> Hi everybody,
>>>
>>> We have talked on and off about making a front-end compiler for
>>> VIFF and today I figured that I would try making such a guy...
>>
>> This is nice, and indeed is exactly what we have talked about doing
>> for some time. If for no other reason, because we promised to do
>> this in CACE :-)
>
> Yeah, I just happened to read an article about writing an interpreter
> or compiler in Python and then I figured that this was a good starting
> point :-)
>
>> Also, we have a new PhD student from August, Sigurd Meldgaard,
>> co-supervised by me and Michael. Sigurd plans to do exactly this
>> sort of thing we are talking about here, so it's important to get
>> him integrated in this work asap.
>
> Cool, that is great news! I've Cc'ed him on this mail just in case he
> wants to get a head start on his PhD... :-)
>
> Sigurd: the entire thread is here:
>
>  http://thread.gmane.org/gmane.comp.cryptography.viff.devel/309
>
> --
> Martin Geisler
>
___
viff-devel mailing list (http://viff.dk/)
viff-devel@viff.dk
http://lists.viff.dk/listinfo.cgi/viff-devel-viff.dk