everything needed.
On the other hand, it is still quicker and more convenient to use the installer,
so I would suggest releasing this VIFF for Windows in this format in the future
along with a ZIP-file as well.
-- Mikkel Krøigård
___
viff-devel mailing
> > if runtime.id == 1:
> > a = runtime.broadcast(1, "foo")
> > b = runtime.broadcast(2)
> > if runtime.id == 2:
> > a = runtime.broadcast(1)
> > b = runtime.broadcast(2, "bar")
> > if runtime.id == 3:
> > a = runtime.broadcast(1)
> > b = runtime.broadcast(2)
> >
> > T
> 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?
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 classe
New submission from Mikkel Krøigård <[EMAIL PROTECTED]>:
With the use of deferreds, some amount of preprocessing is already being done
before the protocol begins proper. But this kind of preprocessing does nothing
for the double auction case where the program branches during execution.
New submission from Mikkel Krøigård <[EMAIL PROTECTED]>:
double_share_random is not fully implemented yet. It lacks the verification
step, as pointed out by the TODO comment in the code.
--
assignedto: mk
keyword: active-security
messages: 68
nosy: mg, mk
priority: bug
status:
> http://hg.viff.dk/viff/rev/19b875e0d65d
> changeset: 685:19b875e0d65d
> user: Martin Geisler <[EMAIL PROTECTED]>
> date: Fri Apr 25 11:54:29 2008 +0200
> summary: Try importing gnutls without introducing an unused binding.
>
Just tested this in Windows. You no longer have to write --
> But to this we must add quite a lot of overhead as explained here:
>
> http://groups.google.dk/group/comp.lang.python/msg/4e0f9800c5898334
>
> Using the heuristic there, an integer takes up 32 bytes and an empty
> list takes up 40 bytes! Ugh...
Well that is a lot of space for simple data types.
> Martin Geisler <[EMAIL PROTECTED]> writes:
>
> > [...] the zipfiles and tarballs now look like this:
> >
> > viff-x.y/
> > viff-x.y/doc/ <-- source files for documentation
> > viff-x.y/doc/api/ <-- epydoc API documentation
> > viff-x.y/doc/html/<-- Sphinx HTML files
> >
> Hello everybody!
>
> I would like to propose that we create a new mailing list called
> viff-patches where people can, well..., send their patches for VIFF.
>
> The idea would be to avoid flooding this list with patches which I
> suspect many of you wont bother reading anyway. I will then integra
> Hello everybody,
>
> As you all know, I have just created two new mailing lists. Who want
> to help administer them?
>
> This involves going to a Mailman page once in a while and basically
> clicking a 'Delete everything' button to delete the spam.
I can do that. I shall have to read the manual
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 thi
> > 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 initializat
Citat Martin Geisler <[EMAIL PROTECTED]>:
> I have already made a script which uses SSH to start any number of
> playes here on DAIMI, and I've used it to test up to 25 players (it
> took 15 ms on average for a 32-bit passively secure multiplication,
> and 19 ms for an actively secure one)
Actually upon reading my own email I realized that I forgot to mention the added
bonus of having real internet communication going on if we have machines outside
DAIMI involved in the testing.
Martin, could you buy a dozen computers and set them up in various locations
around the world? :)
___
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 net
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 modu
Citat Martin Geisler <[EMAIL PROTECTED]>:
> Martin Geisler <[EMAIL PROTECTED]> writes:
>
> > Hi everybody,
> >
> > I have done some testing and come up with some strange numbers. I
> > measured the time each individual multiplication takes by storing a
> > timestamp when the multiplication is sche
Citat Martin Geisler <[EMAIL PROTECTED]>:
> I've looked at the GMPY code, and it is a fairly straightforward
> wrapper for the GMP library, as you describe.
>
> But I don't know if it makes it easier for us to benchmark just
> because it is split into its own C code...
I never said it would. If yo
> 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 fi
> 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 yo
> My idea is that we should have unit tests which target one thing only:
> The tests using BinaryOperatorTestCase targets coercion between plain
> integers, field elements, and Share objects. The tests in
> test_thresholds.py target different thresholds.
You mean the multiplication test for example
New submission from Mikkel Krøigård <[EMAIL PROTECTED]>:
We provide active security protocols, but we cannot handle malformed
messages. For example, it is not clear what to do if the string we are
about to unmarshal is empty.
--
keyword: active-security
messages: 260
nosy: mk
WARNING: This e-mail has been altered by MIMEDefang. Following this
paragraph are indications of the actual changes made. For more
information about your site's MIMEDefang policy, contact
NFIT virus/spamfilter <[EMAIL PROTECTED]>. For more information about
MIMEDefang, see:
http://
Apparently our mail system considers my test program a possible "security
hazard", and I'm not really sure it got through ok. You can find it on
http://tracker.viff.dk/issue48
___
viff-devel mailing list (http://viff.dk/)
viff-devel@viff.dk
http://lists.v
Quoting Martin Geisler <[EMAIL PROTECTED]>:
Hi everybody,
I've just sent 22 patches to the viff-patches list:
http://thread.gmane.org/gmane.comp.cryptography.viff.patches/104
They represent yet another attempt at making a SFDL parser. I say "yet
another" since Mikkel and Sigurd has been wor
I don't care which parser is used -- I just played around with it
to learn more about Pyparsing. However, regardless of the choice,
we should discuss who will commit to take the lead on it.
We should have probably talked about that before we made 3 of them.
I think we did agree on me, but someho
Quoting t.t...@cwi.nl:
Hi all,
A really unpleasant thought has occurred to me: Is VIFF really properly
asynchronous? (Yes, this question is intended to provoke you into thinking
about the issue below. Of course VIFF is asynchronous in the sense that
there are no rounds.)
If I understand/re
Quoting Ivan Bjerre Damgård :
Folks,
I think your precious time is better spent on figuring out a brilliant
solution to handling memory issues with VIFF, than on discussions about what
"asynchronous" really means :-)
Well if you are calling it asynchronous, then it had better BE asynchronous :
Citat af Martin Geisler :
Hi guys,
Take a look at this: we're in the top 10% of all Python projects:
https://www.ohloh.net/p/viff/factoids/1178198
Wow. Very nice!
___
viff-devel mailing list (http://viff.dk/)
viff-devel@viff.dk
http://lists.viff.d
Quoting Ivan Bjerre Damgård :
Quoting Tord Ingolf Reistad :
Hello,
An off topic question about how to write "Secure Multiparty
Compuations", should it be "multiparty" or "multi-party"
The front page of VIFF.dk uses "multi-party", but resent papers
such as "Multiparty computation goes li
Citat af Ivan Bjerre Damgård :
Very interesting!
So if things are as they seem here, the explanation for the strange
behavior would be that the precomputing phase, being more involved
than the online phase, is punished by Twisted (when unhacked). And
this is of course not included in the
Citat af Marcel Keller :
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. To free the memory
Citat af Ivan Bjerre Damgård :
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 is a whole jun
Citat af Håvard Vegge :
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 reconstruct the message"?
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 :
Hi!
I'm trying to do some basic benchmarks with different number of
players. A few questions:
1. Why have VIFF defined the thre
Citat af Tord Ingolf Reistad :
Hello,
As some of you might know I have not programmed that much in VIFF
because I am more familiar with C++ and Java than Python as a
programming language. Therefore I have now created a Java rival to
VIFF. Taking all the good design principles from VIFF an
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 :
Other nice 2. order o
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 no
I had not seen the later replies before answering. My apologies.
The way I've always understood urandom is exactly that. It's
"probably" unpredictable but there's no actual proof of this, like
there would be if you used for example Blum Blum Shub.
I'm sure there are multiple implementations
By the way, I just implemented the Blum Blum Shub generator in Python
just to see how fast it would be compared to urandom. Note here that
urandom is significantly slower than the default Python PRNG, but we
can't use the normal one anyway.
The BBS generator must square modulo n (product of
Of course it is also worth mentioning that this is a very quick and
dirty implementation of BBS. I am sure you can save a lot of time by
implementing this in a clever way.
No tricks were used except for gmpy.
Citat af Mikkel Krøigård :
By the way, I just implemented the Blum Blum Shub
Citat af Marcel Keller :
Hi friends of VIFF,
I've implemented Share and ShareList in C, based on a C implementation
of Deferred. Using the C extension, benchmark.py and aes.py show a speed
up between 50 and 100 percent.
This is very nice, but not entirely surprising I think. I believe this
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 for
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://lists.viff.dk/listinfo.cgi/viff-devel-viff.dk
45 matches
Mail list logo
