For the sake of simplicity, we use a simpler key generation
and triple protocol as ideal functionalities,
to isolate the analysis of our presignature and signature protocols.
The functionalities we use here are perfect, in essence.
The idea behind the presignature functionality
is relatively simple.
One triple is used to help multiply k and x,
and the other contains k itself, which we use to help invert k
for the signature formula.
For convenience, we make it so that the presignature gives us X and x (secret shared).
Another convention is that the same key x is used for an arbitrary
number of signatures, hence N instances.
We use τ as index to denote this instances.
The ideal functionality basically spits out presignatures at will,
all under the same key.
We also get access to k⋅G and kx⋅G, in addition to k−1⋅G.
kx⋅G is actually something you learn from a signature anyhow,
once it’s completed.
Lemma:
For a negligible ϵ, and up to t−1 malicious corruptions, we have:
P[Presign]⇝ϵP[IdealPresign]
Proof:
First, we note that P[Presign]⇝P0,
which modifies Pi to consolidate message sending:
A sketch of the simulator here would be to delay sending messages
from malicious to honest parties until all three bundles have been sent,
and to detect failures early to make all aborts look the same.
The idea behind the simulator is that you generate random values
for the messages you’re going to receive,
and then use those to reverse engineer what the large values
like A,B should be.
■
Signing
Signatures are pretty straightforward once you have presignatures.
The strategy is the same as other simulators in this section, where
we use the fact that only the sum has to verify
correctly, in order to give junk values up until the last moment.
■
The security of using presignatures
Here, we’ve limited ourselves to showing that our protocol
implements “ECDSA with presignatures”,
as far as the security of “ECDSA with presignatures”
as a threshold signature scheme,
see Groth & Shoup 2021.