Okay, I see your point.

I fully agree that we need some infrastructure for loading encrypted
inputs, and specifically that we should implement the cryptosystem from
the paper. That also help making this issue more concrete so that we
know when to call it "done".

>This seems more like a "note to self" than an issue which we
>can act on. I'm giving it an important of 10 at the moment...

Actually I think this one is quite important. Implementing the
encryption scheme outlined in Ivans paper is one of the key issues
that we must fix before VIFF can be used for real applications like
the double auction.

I think this issue is one of the candidates for our next scrum sprint,
but lets postpone that decision to our next meeting :-)

This seems more like a "note to self" than an issue which we can act
on. I'm giving it an important of 10 at the moment...

Quoting Thomas Pelle Jakobsen <tracker@viff.dk>:
> Currently, when someone wish to submit input to the computation, he
> must secret share his input and send each share directly to the
> corresponding server.
>
> This requires authentic and encrypted channels and implies that
> servers must be online when the inputters submit shares. We could
> avoid this by pre-distributing an asymmetric key pair for each server.
> Using the method in the attached document by Ivan Damgaard, the
> inputters can then "encrypt" input using the public keys of the
> servers in such a way that a particular server can "decrypt" using his
> private key and thereby obtain the shares of the input that belongs to
> him.

It should be noted that there is a slightly better method than the one from the
document sent by Thomas. It is described in the attached paper (section 4.1).
It is slightly different from the previous thing, and has the following
advantages: it guarantees that even if the inputter was malicious in creating
the input, the servers will always end up with a  consistent sharing of some
value after decryption. It also guarantees that if one server looses its keys,
it can get them back by talking to the remaining servers. The method is only
described here for 3 servers, but should be easy to generalize, if you know
about PRSS.

regards, Ivan

Currently, when someone wish to submit input to the computation, he
must secret share his input and send each share directly to the
corresponding server. 

This requires authentic and encrypted channels and implies that
servers must be online when the inputters submit shares. We could
avoid this by pre-distributing an asymmetric key pair for each server.
Using the method in the attached document by Ivan Damgaard, the
inputters can then "encrypt" input using the public keys of the
servers in such a way that a particular server can "decrypt" using his
private key and thereby obtain the shares of the input that belongs to
him. 

The benefit is that the encrypted input does not need to be kept
secret, and can e.g. be collected by a web server and stored in a
database until the servers are available.

The implementation of this should preferably involve language and
platform independent data formats (e.g. PKCS12 for keys) such that
input and keys can be generated by all kinds of key generators and
inputters (Java applets, etc).

One final note: We still need some means to ensure that input created
by the method described here actually comes from the right inputter
and is not altered by some man-in-the-middle.