[viff-devel] Confusing behaviour?

2009-03-23 Thread Thomas P Jakobsen
Hi all,

When I execute the attached VIFF protocol on three servers I would
expect all three to ask me to press enter. When all three servers have
done that, I would expect the computation of c to start and that the
servers will eventually finish.

I've run the protocol several times on Linux and Windows. What happens is this:

Sometimes it works out as expected, but at other times only two of the
servers will ask the user to press enter. In some cases, the third
server will ask its user to press enter as soon as one of the two
other servers presses enter. At other times, the third server will
first wake up and ask its user to press enter when both of the two
first servers have pressed enter.

I find this behaviour confusing (..twisted?) and wonder whether it is
a bug or a feature? If it's a bug, could it be related to the issue
discussed in the thread Mystery of the quadratic running time
solved?. I must admit that I haven't followed that thread in
detail...

By the way, the same thing seem sto happen if the protocol, insted of
asking the user to press enter, does some local computations like
quering a database, sleeping, computing primes or the like. Sometimes,
one of the servers will sit still until one or both of the other
servers have finished their local jobs. This was how I initially
stumbled across the problem.

Best regards,
Thomas


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


[viff-devel] A bug in VIFF?

2009-06-12 Thread Thomas P Jakobsen
Hi VIFF guys,

I've implemented a VIFF application involving two binary searches. A
typical trace from one of the players during excecution looks like
this:

search for p1
search for p1: [-1, 4000]
search for p2
search for p2: [0, 4001]
search for p1: [-1, 4000]
search for p2: [0, 4001]
search for p1: [-1, 1999]
search for p2: [0, 2000]
search for p1: [999, 1999]
search for p2: [1000, 2000]
search for p1: [1499, 1999]
search for p2: [1500, 2000]
search for p1: [1499, 1749]
search for p2: [1500, 1750]
search for p1: [1499, 1624]
search for p2: [1500, 1625]
search for p1: [1499, 1561]
search for p2: [1500, 1562]
search for p1: [1530, 1561]
search for p2: [1531, 1562]
search for p1: [1530, 1545]
search for p2: [1531, 1546]
search for p1: [1537, 1545]
search for p2: [1538, 1546]
search for p1: [1541, 1545]
search for p2: [1542, 1546]
search for p1: [1541, 1543]
search for p2: [1542, 1544]

The two searches are independend of each other and they are hence
correctly scheduled to run in parallel by VIFF as indicated by the
trace.

This works all fine with VIFF version e89fb02c5e3d. However, if I
update VIFF to the current tip (8ec45943c12a), strange things start to
happen:

Player 1:
search for p1
search for p1: [-1, 4000]
search for p2
search for p2: [0, 4001]
search for p1: [-1, 4000]
search for p2: [0, 4001]
search for p1: [-1, 1999]
search for p2: [0, 2000]
search for p1: [999, 1999]
search for p2: [1000, 2000]
search for p1: [1499, 1999]
search for p2: [1500, 2000]
search for p1: [1749, 1999]
search for p2: [1750, 2000]
search for p1: [1874, 1999]
search for p2: [1750, 1875]
search for p1: [1936, 1999]

Player 2:
search for p1
search for p1: [-1, 4000]
search for p2
search for p2: [0, 4001]
search for p1: [-1, 4000]
search for p2: [0, 4001]
search for p1: [-1, 1999]
search for p2: [0, 2000]
search for p1: [999, 1999]
search for p2: [1000, 2000]
search for p1: [1499, 1999]
search for p1: [1749, 1999]
search for p1: [1874, 1999]
search for p1: [1936, 1999]
search for p1: [1936, 1967]
search for p1: [1951, 1967]
search for p1: [1951, 1959]

Player 3:
search for p1
search for p1: [-1, 4000]
search for p2
search for p2: [0, 4001]
search for p1: [-1, 4000]
search for p2: [0, 4001]
search for p2: [0, 2000]
search for p2: [1000, 2000]
search for p2: [1500, 2000]
search for p2: [1750, 2000]
search for p2: [1875, 2000]
search for p2: [1937, 2000]
search for p2: [1968, 2000]
search for p2: [1984, 2000]
search for p2: [1984, 1992]
search for p2: [1988, 1992]
search for p2: [1988, 1990]

It seems from the above that one of the players continue with one of
the searches (search for p1) while another player continues with the
other search (search for p2). This doesn't make sense since each step
in the binary search is synchronized, e.g. the players have to engage
in a comparison of a secret share in each step. The above trace is
just an example; it varies for each time I run the program.

Also, after the above trace, the players now deadlock where they used
to continue with other parts of the program.

It seems that the new code causes the two independent callback chains
for each binary search to somehow mingle in a wrong way.

Note also that I haven't enabled the new reactor, just installed the
new VIFF tip code. If I enable the new reactor, e.g. by including

import viff.reactor
viff.reactor.install()

in the code, I get the following exception:

Traceback (most recent call last):
  File C:\Python25\Lib\site-packages\viff\runtime.py, line 401, in
inc_pc_wrapper
return method(self, *args, **kwargs)
  File C:\Python25\Lib\site-packages\viff\passive.py, line 109, in open
self.activate_reactor()
  File C:\Python25\Lib\site-packages\viff\runtime.py, line 838, in
activate_reactor
reactor.doIteration(0)
  File C:\Python25\Lib\site-packages\viff\reactor.py, line 42, in doIteration
self.runUntilCurrent()
--- exception caught here ---
  File C:\Python25\Lib\site-packages\twisted\internet\base.py, line
729, in runUntilCurrent
f(*a, **kw)
  File C:\Python25\lib\site-packages\twisted\internet\defer.py, line
243, in callback
self._startRunCallbacks(result)
  File C:\Python25\lib\site-packages\twisted\internet\defer.py, line
298, in _startRunCallbacks
raise AlreadyCalledError
twisted.internet.defer.AlreadyCalledError:

whereafter the players continue with the strange search as shown in
the above traces.

Since the only change between the right and the wrong behaviour of my
binary search algorithm described above was the VIFF update - my own
code remained unchanged - I guess that this is caused by a bug in the
new VIFF code. Do anyone have similar experiences? Anyone having a
clue of this bug?

Best 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] A bug in VIFF?

2009-06-16 Thread Thomas P Jakobsen
Problem seems to be fixed.

I used addCallback several places where I should instead have used
schedule_callback. The new changes to VIFF somehow triggered this bug.


Best 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] A java implementation of VIFF

2009-08-18 Thread Thomas P Jakobsen
Nice work!

It would be interesting to see how it performs compared to VIFF.

Best 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] Query from the University of Surrey

2010-02-23 Thread Thomas P Jakobsen

 When I run the Millionaires example (again with --no-ssl option)  with the 
 Path set to point to Python 2.6.4, I get the following error message.

 Traceback (most recent call last):
  File generate-config-files.py, line 57, in module
    from viff.config import generate_configs
 ImportError: No module named viff.config


This exception typically shows up if VIFF is not on the PYTHONPATH.
When Python sees an import statement, it looks for the needed
packages on the PYTHONPATH.

The solution would be to either

1) Download and install the VIFF .exe installer from viff.dk or

2) Download the VIFF source code from viff.dk and run setup.py
install when you are in the root of the source tree.

These steps will both install VIFF in C:\Python26\Lib\site-packages
which is always on the PYTHONPATH. A third alternative would be to
include the path to the VIFF source code in an environment variable
called PYTHONPATH.

Hope this helps,
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

2010-07-06 Thread 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] [issue83] Use cryptographically secure prng

2010-08-12 Thread Thomas P Jakobsen

New submission from Thomas P Jakobsen t...@cs.au.dk:

Currently, VIFF uses a pseudo-random number generator with weak security 
properties (Mersenne-Twister). We should rather use a cryptographically 
strong prng.

See discussion at 
http://article.gmane.org/gmane.comp.cryptography.viff.devel/834.

--
importance: 90.0
messages: 316
nosy: Marcel.keller, mg, mk, tpj
status: unread
title: Use cryptographically secure prng
type: bug


VIFF Issue Tracker trac...@viff.dk
http://tracker.viff.dk/issue83

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