The previously described Publish-RPi (Algorithm 8) can be combined with the SPDZ
classification protocol Classify-IPi (Algorithm 4) in a straightforward manner to obtain
a protocol for sharing the input of any third party. However, this version of the algorithm requires heavy computation and communication from the input party, who has to take part in a zero-knowledge proof. This is not efficient in many practical settings where we could have a variety of input devices, for example, smartphones and tablets.
There is a different protocol Classify-IP?i in Algoritm 13 that uses ideas from the Singles protocol. In a way, the input party runs the single generation by itself and sends the corresponding share parts to the computing parties. Of course, instead of making a random share, it creates a share for its secret. The only addition is that the computing parties have to notify the input party if they accept this share. This means that the input party should wait and check that its input was accepted before it can know that it has correctly inserted the data.
Algorithm 13 Receiving an input from (non-computing) IPi (Classify-IP?i)
Data: Input party IPi has a secret x
Result: Computing parties CPi have a valid share representation [[x]]N
1: Round: 1 2: CPi fixes ∆ = 0 3: IPi generates x1, z2 ← ZN, r, t ← Z∗N 4: IPi computes x2 = x − x1 5: IPi computes c = ([k])xpk2 · Encpk(−z2, t) 6: IPi sends x1, c, r to CP1 7: IPi sends x2, z2, ([x1])pk = Encpk(x1, r), t to CP2 8: Round: 2 9: CP1 computes z1 = k · x1+ Decsk(c) 10: CP2 computes c∗ = ([k])x2 pk· Encpk(−z2, t) 11: CP2 sends ([x1])pk, c∗ to CP1 12: Verification:
13: CPi verifies that ([x1])pk is a valid ciphertext
14: CP1 verifies that c∗ = c
15: CP1 verifies that it received ([x1])pk = Encpk(x1, r)
16: CP1 proves z1+ z2 = k · (x1+ x2) to CP2 using CdsZKTags
17: CP1 and CP2 notify IPi about the verification outcome
Theorem 4.5.1. Protocol Classify-IP?i in Algorithm 13 for collecting inputs from input parties is correct.
Proof sketch. The correctness of additive shares is clear by the definition as x = x1+
x2+ ∆ = x1+ x − x1+ 0 = x. If CP1 accepts the commitment then it is valid. Finally,
we need that the MAC tag is correct:
z = z1+ z2 = k · x1+ k · x2− z2+ z2 = k · (x1+ x2) ,
thus, in case of honest participants the zero-knowledge proof succeeds and the share is correctly formed.
There are three potential security risks in this protocol: (1) CPi might modify the
share, (2) CP2might modify the share, and (3) IPimight try to give inconsistent share
representation. However, IPi can always affect the outcome by inputting a maliciously
chosen value x instead of the valid input value. Still, by security definition regardless of the choice of x it can only input a valid representation [[x]]. This version of the protocol is only usable if IPi is not one of the computing parties and does not collude
with them. The former is not a restriction as we have a simpler protocol for CPi to
classify inputs, but the latter may be too restrictive for practical applications.
Theorem 4.5.2. Protocol Classify-IP?i for collecting inputs from input parties is per- fectly secure against corrupted CP1 and IPi and computationally secure against cor-
rupted CP2 with additional 1p error probability, assuming a computationally IND-CPA
secure cryptosystem and modulus N = pq, where p is the smaller of its prime factors. Proof sketch. The principal ideal functionality of this protocol would be such that the IPi gives x to the TTP and TTP gives shares of x to the computing parties.
by IPi. Hence, we define an ideal model where IPi gives x, x1, z2 and r to TTP, who
creates the remaining z1 and forwards these to the computing parties. After that, the
computing parties notify the TTP about accepting or rejecting these shares and the TTP forwards the outcome as Success or Failure to all parties.
Corrupted CP1. The simulator at first receives x1, z1, r from the TTP. It then
computes c = Encpk(z1) · ([k])−xpk1 = Encpk(z1 − k · x1) and sends x1, c and r to the
corrupted CP1. By definition CP1 gets the output z1 as the one given by the TTP.
In the following, the simulator simulates the messages from CP2 as Encpk(x1, r) and
c∗ = c. For the zero-knowledge proof, the simulator can define x∗2 = −x1 and z2∗ = −z1
to behave as an honest verifier for the case 0 = k · 0. This can be done as the proof does not leak x∗2 and z∗2 and, therefore, the corrupted CP1 sees the same view that it
would in the real world. Finally, the simulator receives Continue or Abort from the corrupted CP1 and forwards this to the TTP. The outputs of the real and simulated
ideal world coincide as in case the sharing succeeds both computing parties have the same output shares in both worlds and in case the sharing does not succeed they have both seen the same shares in these two versions of the protocol.
Corrupted CP2. In case of the simulation for corrupted CP2, we assume that the
shared setup step was also simulated, so that the simulator has kS, whereas the CP2
has ([kS])pk. The simulator receives x2, z2 and ([x1])pk from the TTP. It has to specify
the value t, that it can do by generating it as honest IPi would. It then forwards x2, z2,
([x1])pk and t to CP2. On messages c∗ and ([x1])pk from the corrupted CP2, the simulator
verifies that the ([x1])pk is the same as sent to CP2 and that c∗ = ([kS])xpk2 · Encpk−z2, t.
If these are incorrect, then the simulator outputs Failure, otherwise it continues the simulation. For the zero-knowledge proof, the simulator has ([x1])pkand ([kS])pkmeaning
that it can also compute ([z1])pk = (([x1])pk·Encpk(x1))kS·Encpk(−z2) = Encpk(x·kS−z2).
Therefore the simulator has all the correct inputs for CdsZKTags and it could behave as a simulator for the proof. The outputs coincide as for a corrupted CP1.
Corrupted IPi. The simulator for a corrupted IPi at first receives x1, c, r, x2,
z2, ([x1])pk and t from the corrupted IPi. In then verifies that ([x1])pk = Encpk(x1, r)
and c = ([k])x2
pk · Encpk(−z2, t). If these hold, then it sends x, x1, z2 and r to the TTP
and forwards the Success or Failure to the corrupted IPi as messages from CPi. If
the initial check does not verify, then it sends Failure to the IPi and notifies the TTP
that it does not participate in the protocol, which means that the protocol is a failure for all parties. The output distributions coincide because the simulator performs the same checks as the real functionality would to ensure the correctness of the IPi.
Actually, Classify-IP?i is also secure if CP1 and IPi are corrupted by the same
adversary, but insecure if CP2 and IPi are corrupted together. In the latter case, the
adversary could use one run of the protocol to check if some ciphertext that it sends as c is an encryption of some fixed message m. In practice, this protocol can be fairly securely used if CP1 only publishes encryptions of uniformly distributed elements in
ZN and the number of expected inputs is small, or if the input party is authenticated
and one party should input a limited number of elements. In this case, the probability of an input party guessing the correct m within the expected number of input attempts can be made arbitrarily small. For full security, we could define a zero-knowledge proof where IPi or CP2 proves to CP1 that c or c∗ is computed correctly. It would be more
reasonable to define this for c∗ because we are more likely to have miners with bigger computing capability. Besides, we can always use Classify-IPi with Publish-RPi, if
analogous proof.
We have the anti-framing property, as after this protocol, all parties know that the share was correctly formed. Intuitively, as in the Singles protocol, framing CP2
is infeasible because of the zero-knowledge proof, which shows that in this step CP1
could correctly open this share. Analogously, framing CP1 is impossible because it can
convince itself that the commitment ([x1])pk is correct. However, if any of the checks
fail during the protocol, then the computing parties can not easily verify whether the input party or the other computing party is acting maliciously.