One sub-component used a couple of times is a combined broadcast commitment
functionality, implemented via echo broadcast.
In a nutshell, the idea behind echo broadcast is to ensure that a party
sends the same message to all others.
We accomplish this by sending a hash of all the messages we’ve received
to everyone else, thus enabling us to realize if a different message
was sent in the first round.
Definition (Echo Broadcast Protocol):
The broadcast protocol P[EchoBroadcast] is defined
as follows:
We model this hash function as a random oracle here.
The functionality that this implements is basically what you’d
expect.
The parties have to set their broadcast value, and then the functionality
forces them to send it to all others.
However, there is a sort of catch, in that adversaries
can set a “trap” value, which will cause an abort later if the wrong
broadcast value is set after the trap.
This reflects the fact that adversaries can send their confirmation
message early, thus potentially causing an abort later.
In practice this won’t matter for our purpose of using broadcasts
for commitments, because the commitment values will be random,
and thus not trappable.
Definition (Ideal Broadcast Protocol):
The protocol capturing the ideal behavior of broadcast
is defined as follows:
having split the game into an honest part, and a malicious part,
long with the ideal functionalities.
The malicious part will slowly become our simulator.
Our next step will be to modify the honest part to send both
the hash of their messages, and an entire vector confirmation.
The malicious part will ignore this new information,
giving us an identical game.
Now, we can have the honest parties omit their hash completely,
only sending the vector.
This requires moving some of the hashing logic into the malicious part,
and the verification check at the end,
but otherwise gives us an identical game.
Now, except with negligible probability, a hash with no pre-image
will cause the final verification check made by honest parties
to fail, so we can instead cause an abort when the adversary
tries to send such a hash,
allowing us to always extract a pre-image, or to abort:
At this point, we’ve actually written a simulator
for a protocol P0, which is like our initial
protocol, except that the parties send their entire vector,
rather than their hash.
This shows that P[EchoBroadcast]⇝P0.
Now, we employ a classic trick, and are trying to get
rid of F[SyncComm].
Our strategy to do this will be to inline all of the variables
in a common mutable functionality:
The only reason the honest check will fail is if the adversary
sends to different messages to honest parties,
causing their confirmations to differ.
We can
detect that in ΓM instead, replacing the honest check.
As suggested by the introduction of this broadcast functionality,
we now have a new protocol P1,
and have shown that P0⇝P1
by our game hopping.
We’re not quite done yet, because the trapping here is a bit too strong,
in that the adversary can trap even after a broadcast value has been
set.
We can simulate this freedom away.
This is a simulator for P[IdealBroadcast],
which concludes our proof, via the logic:
P[EchoBroadcast]⇝P0⇝P1⇝P[IdealBroadcast]
■
Commitments
Our main application of broadcast will be to define a commitment protocol.
The basic idea is that you commit to a value by hashing it,
along with a random salt,
and then broadcast that commitment.
Later, you can open the value by sending it along with the salt.
The ideal functionality this is supposed
to implement is relatively straightforward.
You set a commit value,
and can wait for others to commit as well.
Finally, you can open, which doesn’t allow you to actually
change the value you’ve committed to, it just makes it now visible to others.
We also have the usual abort points remaining in the protocol.
Now, a trap value needs to be provided before the commitment
value is known.
However, for honest parties, these commitment values
are in all likelihood freshly sampled, because of the entropy
in r.
This means that trapping honest values is useless,
since except with negligible probability, it has no effect.
From this we see that we’re in fact simulating a protocol P1,
which is like P[IdealBroadcast],
except that trapping is not possible.
Let’s unroll that protocol, to get:
At the end of WaitOpeni, we check that the opened
values match the commitments.
Because honest parties will always open the right values,
we can instead limit the check to malicious parties.
Now, because of the entropy of the r values, in all likelihood
the random oracle will not have been queried
at that value before, and so we can instead assume that the value
is random, and then backfill it later.
Thus, we have honest parties broadcast completely random commitments,
and then program the random oracle after they open the commitment.
Next, except with negligible probability we can extract preimages
of commitments, since a commitment that hasn’t come from the hash
function will fail with probability ≤2−2λ.
Next, instead of checking for bad openings inside honest parties,
we can instead have malicious parties directly cause
a stop once they send a bad value.
At this point, the malicious party can’t actually send honest
parties an opened value that’s any different than the one they
used to generate their initial broadcast hash.
We can now rewrite the adversary to use the ideal commitment
functionality instead.