[zapps-wg] Eliminating the possibility of backdoors with high probability

Sean Bowe sean at z.cash
Mon Nov 13 16:16:18 EST 2017


There are three ways that a participants' toxic waste can be compromised:

1. the participant is dishonest and keeps the toxic waste around
2. the toxic waste is extracted from the machine, either from a side
channel attack or because the toxic waste still "exists" in the
machine somewhere
3. the participant's code, compiler, operating system or hardware are backdoored

Our solution to #1 is to have large numbers of diverse participants,
to virtually eliminate the chance that all of them are dishonest and
secretly colluding with each other. I am very confident in this
approach.

Many of us are solving #2 by performing the computations on hardware
we have randomly plucked from a store somewhere, in an environment
(like a Faraday cage, or out in a field somewhere) where side-channel
attacks are unlikely. And of course, completely destroying the machine
afterward. I am very confident in this approach.

However, we don't really have a good handle on #3. Right now,
participants are using the `powersoftau` code that I've written in
Rust. It is possible to change the code or even make an alternative
implementation, but that only gets you so far. You still have to hope
your OS/compiler/hardware are not backdoored.

I think there's a nice solution to this problem which is inspired by
an idea that Brian Warner had.

Currently, the code I've written takes some randomness from the system
and mixes it with some user-supplied randomness. Instead, imagine
using randomness supplied by the participant exclusively. (One way the
participant can obtain it is with a boggle set.)

The trick is that the participant performs the computation N times,
each time with different randomness. This produces N response files.
Now, the participant randomly chooses N-1 of the response files and
reveals the randomness for them, and destroys the randomness of the
last response file -- which is their contribution to the ceremony. The
participant (and the general public) can perform the computations
again on their machines to check that the same response files are
produced for the ones we've revealed randomness for.

As N increases, the probability that any backdoor in the code,
compiler, hardware, operating system etc. could have tampered with the
entropy approaches zero. Now there is just one remaining problem: how
do we get the response files out of the machine without the backdoor
potentially sneaking the entropy over the channel? DVDs are a good
approach if it's possible to create many of them and then analyze them
for any differences or hidden information.

(The original idea that Brian and Zooko briefly considered for the
Zcash ceremony last year was similar, except it involved one of the
participants revealing all their entropy at the end, and the rest
destroying theirs. This is because the previous protocol couldn't
support participants performing multiple computations, because they
had to commit to their entropy at the very beginning. The new protocol
does support participants performing multiple computations with
different entropy, though!)

Sean



More information about the zapps-wg mailing list