it are the same.
Best regards,
Marcel
Marcel Keller wrote:
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.
The code is in my repository: http://hg.viff.dk
Dear Lars,
thanks for pointing it out. It is now fixed in the official repository.
Best regards,
Marcel
Lars Krapf wrote:
Hello VIFF-team
I would like to suggest the following patch to viff/comparison.py:
159c159
l = int(self.options.security_parameter +
Thomas P Jakobsen wrote:
The urandom is os-specific:
This function returns random bytes from an OS-specific randomness
source. The returned data should be unpredictable enough for
cryptographic applications, though its exact quality depends on the OS
implementation. On a UNIX-like system this
Hi Joel,
Is it still necessary to run `viff.reactor.install()` as described in
http://www.mail-archive.com/viff-devel@viff.dk/msg00657.html in
order to utilize the VIFF reactor?
- If so, would it be possible to fix that?
I don't see a good way to that, for the following reasons:
- To change
Hi Claudio and Jesper,
In the code review of the OrlandiRuntime we found two points, we want to
discuss with you.
Step 3 of the triple generation protocol says: Coin-flip a subset
\fancy_T \subset \fancy_M of size \lambda(2d + 1)M. The current
implementation loops over the elements in
Claudio Orlandi wrote:
On Wed, Nov 4, 2009 at 5:46 AM, Marcel Keller mkel...@cs.au.dk wrote:
Hi Claudio and Jesper,
In the code review of the OrlandiRuntime we found two points, we want to
discuss with you.
Step 3 of the triple generation protocol says: Coin-flip a subset \fancy_T
\subset
Claudio Orlandi schrieb:
On Wed, Nov 4, 2009 at 10:15 AM, Marcel Keller mkel...@cs.au.dk wrote:
Claudio Orlandi wrote:
On Wed, Nov 4, 2009 at 5:46 AM, Marcel Keller mkel...@cs.au.dk wrote:
Hi Claudio and Jesper,
In the code review of the OrlandiRuntime we found two points, we want to
discuss
make it an option.
On 28/10/2009, at 20.01, Marcel Keller wrote:
Hi Janus,
do you still need the timing output in the update callback in
Runtime.preprocess()? It makes benchmarking the usual runtimes very
noisy because the update callback is called many times there.
Best regards,
Marcel
Hi Janus,
do you still need the timing output in the update callback in
Runtime.preprocess()? It makes benchmarking the usual runtimes very
noisy because the update callback is called many times there.
Best regards,
Marcel
___
viff-devel mailing list
Hi Janus,
I remember you saying today that the preprocessing in the OrlandiRuntime
is more efficient per item the more items are requested. Is that
correct? I ask because in my optimizations, I limited the items being
preprocessed per call in order to save memory. I would of course drop
that
Martin Geisler wrote:
Janus Dam Nielsen janus.niel...@alexandra.dk writes:
Hi Marcel,
I am not opposed to your suggestion. However I would like to point out
that in VIFF you compute on shares and not field elements!
Well, we've actually made the outer runtime interfaces in such a way
that
Hi,
There are two talks about how to implement AES efficiently, this one
http://www.hyperelliptic.org/SPEED/slides09/kasper-aes_speedcc09_slides.pdf
describes on slide 9 how one will typically combine SubBytes, ShiftRows,
and MixColumns into one operation operating on diagonals. I don't
Hi Janus,
I am not opposed to your suggestion. However I would like to point out
that in VIFF you compute on shares and not field elements!. Computing
directly on the field elements is hacking the abstractions of VIFF.
I don't think so. Since I work with VIFF, it treats field elements as
Hi friends of VIFF,
I've now implemented a special reactor for VIFF, based on the standard
SelectReactor. The new reactor should make non-trivial programs
considerably faster, e.g. computation of 10 AES-blocks in parallel from
over 6 seconds to 2.3 seconds per block (3 players, passive
Hi friends of VIFF,
Who is working with non-default reactors, such as gtk2reactor? How do
you deal with the fact that VIFF might block the reactor for a long time
which might render the GUI non-responsive?
I'm currently working on a special reactor for VIFF to get more control
over the
I think the problem is the following: Every players sends its id on a
new connection, and the connection is considered to be set up when this
id arrives. So it may occur that a player has received the ids from all
other players and wants to send its id to other player(s). But nothing
is sent
Hi Ivan,
I just wanted to say that I think it would be great if you would
implement a version of your proposed two-threaded solution. I do not
have a firm grasp of all the programming details, but it does seem that
the overall idea is converging, and that some time soon the best way to
judge
You're talking about this two-threaded solution as if it is something
that exists and will solve all our problems...
No, for now, it's just an imagination in my mind, a proposal for the
next meeting, and a strong feeling that it's the right way to do it.
But I still haven't seen it, and I
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 of the shares and to
send
19 matches
Mail list logo
