> I've put some changes to it here -- it's only style changes in order to
> make it more "pythonic" :-) Please pull from this repository:
>
> http://bitbucket.org/mg/viffbench-mg/
>
> I have not really tested the changes, expect by running pyflakes on the
> source.
Thanks a lot. I'll take a look
>>
>> I vote for MPC. It sounds better when you pronounce it.
>
> I agree, I also mostly skip the "S" since who wants to hear about
> insecure multiparty computation anyway? :-)
There's a lot of interesting insecure multiparty computation going on.
What I mean is that there is a whole research fie
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 W
Thanks for the reply.
> However, your problem probably could be fixed by synchronizing before
> blocking:
>
> sync = runtime.synchronize()
> sync.schedule_callback(blocking_code())
Yes, I was thinking the same thing. Another way of avoiding the
problem is to place initial local computations outsi
Thanks for the clarification. I erroneously assumed that blocking
stuff was ok in Twisted as long as it happens before any
communication. But it makes good sense that one should avoid this
anywhere in a Twisted program.
Regards,
Thomas
2009/3/26 Martin Geisler :
> Thomas P Jakobsen wri
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
New submission from Thomas P Jakobsen :
The runtime currently has a schedule_callback. It should also have a
schedule_errback and maybe a schedule_callbacks method.
--
keyword: patch
messages: 313
nosy: mas, mg
status: unread
title: schedule_errback
type: bug
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
h
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
>> 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.
I think what Tord means is that the players
>> I am on a Windows XP machine. I tried with the latest versions of the
>> the components from the respective websites, but the apps from the
>> VIFF folder threw up errors. I realize I should have taken note of the
>> error messages - sorry about that. So I installed slightly older
>> versions (P
>
> 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
> from viff.config import generate_configs
> ImportError
Hi all,
In the CACE project (http://www.cace-project.eu) we've just created a
compiler that can translate MPC programs written for FairplayMP to
VIFF programs. VIFF and Fairplay each have their benefits. If you
write your MPC program in the Fairplay language, you can now freely
decide which MPC en
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 prob
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 itse
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 execut
Hi all,
As you may or may not know, running the same VIFF program more than
once using the same set of player configuration files is insecure when
the runtime relies on pseudo-random secret sharing. This is the case
for e.g. the PassiveRuntime.
This is not a bug, but rather a consequence of the w
New submission from Thomas P Jakobsen :
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
On Thu, Aug 12, 2010 at 12:06, Martin Geisler wrote:
> Would it not be fairly easy to let each of the players secret share a
> random integer, add all the shared numbers, open the result, and use
> that as the computation ID? That is, automate this so that you don't
> have to agree on a certain c
> There is also an Orlandi runtime and a BeDOZa runtime (under
> development). They work for 2 parties and guarantee security against
> active adversaries (paillier.py is only for passive security).
>
> Claudio
The current implementation of the Orlandi runtime found in orlandi.py
unfortunately dep
20 matches
Mail list logo
