It would definitely be better to have an online HTML file. I think we
should replace the the INSTALL file with a simple one like that:
Installation Instructions
==
Please see http://viff.dk/installation.html
What do people think of a scheme like this? Is it
New submission from Mikkel Krøigård [EMAIL PROTECTED]:
The Runtime class keeps growing as more and more functionality is put into it.
An option would be to split it into a basic Runtime which provides communication
and nothing else. More functionality could be provided by mix-in classes. See
Well, there are many more or less interesting conclusions to draw from your
benchmark, Marting. Not surprisingly, matrix multiplication turns out to be
expensive. It is worth considering using a non-naive algorithm for this
multiplication, but I am not convinced there is very much to gain.
One
Well, there are many more or less interesting conclusions to draw
from your benchmark, Martin. Not surprisingly, matrix multiplication
turns out to be expensive.
Hmm... I did see that there were a bunch of calls to __mul__ in
matrix.py, but I thought they came from the initialization of
Citat Martin Geisler [EMAIL PROTECTED]:
In both plots we see that the first multiplication takes very long, it
is sort of waiting on the other multiplications. I think this is
because we're not yielding to the reactor when we start all the
multiplications.
This also means that no network
Citat [EMAIL PROTECTED]:
I think there was earlier some version where arithmetic was done by calling
some
external C code.
We are easily able to switch between gmpy (which is implemented in C) and Python
arithmetic, if that's what you mean.
I remember trying out how to implement Python
New submission from Martin Geisler [EMAIL PROTECTED]:
I think we could think about shipping the ConfigObj library directly
with VIFF. The ConfigObj library is self-contained in a single .py
file, and including it with VIFF would save people using Windows the
trouble of copying this file to
Tomas is right, of course. For the passive case, using the first 2t+1 players
always works, and for the active case, we do not use the
local-multiply-and-reshare method anyway.
The thing is, I always just assumed that we always used the same set of shares,
and it is kind of easy to miss if you
Citat af Marcel Keller mkel...@cs.au.dk:
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.
Citat af Ivan Bjerre Damgård i...@cs.au.dk:
It can definitely be useful to have a broadcast method, for instance
to complete the implementation of the asynchronous maliciously
secure protocol, we will need broadcast.
But one needs to be careful about what kind of security we want.
There
Citat af Håvard Vegge hava...@stud.ntnu.no:
Hi!
I'm trying to do some basic benchmarks with different number of
players. A few questions:
1. Why have VIFF defined the threshold t to be the number of corrupt
players, while the classical literature defines it as t
participants can
. It has been about forever
since I looked at the VIFF code, but I think I'll try this out, see if
I can get the bug as well.
Mikkel Krøigård wrote:
Citat af Håvard Vegge hava...@stud.ntnu.no:
Hi!
I'm trying to do some basic benchmarks with different number of
players. A few questions:
1
I think it deserves to be mentioned that you can do conditional
statements on secret values in some cases. A simple case is easy to
implement with the other primitives, but then of course you can be
annoying and start nesting them.
Citat af Sigurd Torkel Meldgaard s...@cs.au.dk:
Other
Indeed it should satisfy those properties. Say if you Shamir share
something, the adversary might get t shares in order. If it can guess
the next bit with non-negligible advantage, this will completely break
our claim that the adversary has no information on the secret.
Luckily it should
Hello,
We've been trying to run an MPC LP solver (by Tomas Toft) for a while
now and can't get it to work for examples of a more realistic size.
One problem we're having right now is that using the Toft07
comparison, we can basically get VIFF to drop to 0% CPU usage and just
sit there
needs two
players. But it gaves errors too with two players.
I think Viff only works with at least three players. Am I correct?
Same as above :)
Regards,
Mikkel Krøigård
___
viff-devel mailing list (http://viff.dk/)
viff-devel@viff.dk
http
16 matches
Mail list logo
