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
Hello VIFF-team
I would like to suggest the following patch to viff/comparison.py:
159c159
< l = int(self.options.security_parameter +
math.log(dst_field.modulus, 2))
---
> l = self.options.security_parameter +
math.log(dst_field.modulus, 2)
otherwise the l in the next line:
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
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 +
math.log(dst_field.modulus
It 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 itself as well as most protocols implem
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 will query /dev/urandom,
and
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
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 w
Marcel Keller writes:
> Thomas P Jakobsen wrote:
>
>> If not, I guess we'll have to use some external package (openssl?) or
>> implement our own algorithm.
>
> viff.util.rand is used to make all randomness replayable, which
> already helped me to find bugs triggered by certain randomness. I
> wou
Mikkel Krøigård writes:
Hi everybody
> 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 informa
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
12 matches
Mail list logo
