Securely running the same VIFF program multiple times

[Thomas P Jakobsen]

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 way in which we use
pseudo-random secret sharing. In order to maintain security, a new set
of player configuration files has to be generated for each run.

In some practical settings this turns out to be inconvenient. So we
recently added a changeset (1538:9d4f9551644c) that fixes this. It
means that one no longer has to use fresh configuration files for each
run. Instead, there's now a command line option called computation-id,
e.g.

python my_viff_program.py --computation-id=42 player-1.ini

When using runtimes based on pseudo-random secret sharing, like
PassiveRuntime, one can then safely reuse the configuration files as
long as the computation ids are unique. That is, for each run with a
given set of configuration files, the players should agree on a
computation id that has not been used before for that set of
configuration files.

A consequence of this is that the length of all program counters are
increased by one. This means that the data that needs to be sent
across the network increases a bit, but we expect it to have only
negligible impact on performance.

Regards,
Thomas

[Martin Geisler]

Post by Thomas P Jakobsen
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 way in which we use
pseudo-random secret sharing. In order to maintain security, a new set
of player configuration files has to be generated for each run.
In some practical settings this turns out to be inconvenient. So we
recently added a changeset (1538:9d4f9551644c) that fixes this. It
means that one no longer has to use fresh configuration files for each
run. Instead, there's now a command line option called computation-id,
e.g.
python my_viff_program.py --computation-id=42 player-1.ini
When using runtimes based on pseudo-random secret sharing, like
PassiveRuntime, one can then safely reuse the configuration files as
long as the computation ids are unique. That is, for each run with a
given set of configuration files, the players should agree on a
computation id that has not been used before for that set of
configuration files.

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 computation ID in advance.

[Thomas P Jakobsen]

Post by Martin Geisler
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 computation ID in advance.

That might well be a better solution. But there's a trade-off; it
makes it easier to use, but slows down the execution time. Of course,
for most applications a single secret sharing and an opening is
affordable.

Another potential issue is that some runtimes may require prss in
order to share and/or open values. That would give us kind of a
chicken-egg problem.

Anyway, the best solution may be to let it up to each runtime to
decide what to do on startup and which parameters to use.

Regards,
Thomas

[Martin Geisler]

Post by Thomas P Jakobsen

Post by Martin Geisler
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 computation ID in advance.

That might well be a better solution. But there's a trade-off; it
makes it easier to use, but slows down the execution time. Of course,
for most applications a single secret sharing and an opening is
affordable.

Yes, I don't think performance is an issue here.

Post by Thomas P Jakobsen
Another potential issue is that some runtimes may require prss in
order to share and/or open values. That would give us kind of a
chicken-egg problem.

I meant that they should just Shamir share the random number. Malicious
parties may then of course produce an inconsistent sharing and this will
result in the parties using different seeds for PRSS. I think that would
be no worse than if the parties had used different command line options.