Cait-Sith Security (3): Multiplication and Triples
We basically start with the ideal
functionality for multiplicative-to-additive conversion (MTA),
from HMRT21.
We slightly simplify their functionality, by giving the adversary
more power to corrupt the result.
The basic idea is that we convert a secret s=a⋅b into shares
α,β such that α+β=s.
But, the malicious party can cause the result
to fail, by instead being a secret sharing of s+Δ.
Multiplication
Next, we consider multiplication using this functionality.
First, we need to take a detour, to consider using two instances
of the functionality together.
This is a bit of a simplification, in that there’s only a single Δ
for the result, rather than 2.
This will make our life a bit easier later.
Lemma:
For a negligible ϵ, and any number of malicious corruptions, we have:
P[MTA2]⇝ϵF[MTA2]
Proof:
First, the case of all corruptions is trivial, as with any protocol,
and the protocol clearly functions in the case of no corruptions,
so we consider the case where, without loss of generality, the second
party is corrupt.
The basic idea is that the adversary can only tell whether or not
they’ve received correct shares of the MTA by summing everything
together, from both the honest and malicious parties,
because of this, we can give them junk until they get the second
share, in which case we need to make it so that the sum is preserved.
We can do this by cheating with Δ1+Δ2−α,
and using the result of the “double MTA” as their second share.
When we sum everything up, we’ll get the right share.
■
Next, let’s look at the actual multiplication protocol.
The basic idea is that you need to do MTAs between each pair
of parties.
One bit of notation we use is that we use ij as indices,
whereas in reality this only ranges of pairs such that i≤j,
to not repeat the same pair twice.
We also use Flipi(a,b) to denote a process
whereby for each pair i,j, one party uses a and the other b.
We assume some common convention for doing this flip.
This gets us to the ideal functionality for multiplication:
There are two ways the adversary can tamper with the result here.
They can cheat via Δ, as one might expect,
or they can cheat by using inconsistent shares in the multiplication.
This is reflected by using an entire vector a_∙,b_∙,
rather than a single scalar.
Lemma:
For some negligible ϵ, and any number of malicious corruptions, we have:
In essence, this is just a more complicated variant of the simulator from the previous proof.
All that matters is that the sum of all shares is correct,
so we can just keep using junk up until the very last share,
at which point we need to ensure that the result is correct.
We also need to aggregate the cheating values used by all of the malicious
parties,
in order to get just a single bias in the end.
This protocol is very long, but relatively straightforward.
The idea is that you first generate a and b, and commit
to their sharings as polynomials.
Then you prove that you know your secret share,
and convert those to threshold shares.
Concurrently,
you also run multiplication to get a secret sharing of a∗b,
and run a little protocol to learn a∗b⋅G,
using ZK proofs to make sure that this check value C has been
learned correctly.
Finally, you can use this to verify your share of the multiplication,
detecting cheating there, including inconsistent shares.
The ideal triple generation protocol is as you might expect,
with the functionality itself doing the multiplication perfectly.
However, we once again have the various tweaks to secret sharing
induced by the commit reveal paradigm.
See the key sharing document for some discussion about
these artifacts, which naturally show up here again.
Lemma
For a negligible ϵ, and up to t−1 corrupt parties:
P[Triple]⇝ϵP[IdealTriple]
Proof
Clearly, P[Triple] is simulated by the following
protocol making use of P[SplitShare] twice:
The vast majority of this simulator is just mindless bookkeeping.
The main part of interest is the C^ function,
which basically simulates the expected
result of the multiplication, based on the bad values used by the adversary.
In essence, this reflects the fact that the adversary learns
nothing about the other parties shares
through the combination of the faulty multiplication protocol
and share check phase,
because they can calculate the results “in the exponent”
already.
That’s the only real tricky part of the simulator,
the rest is just adding in necessary checks ourselves,
and coalescing contributions from adversaries, as we’ve done many times.