[zapps-wg] Powers of Tau Ceremony Proposal

Sat Nov 11 17:31:53 EST 2017

Thanks Jared! Awesome! I've verified the contribution and put your
response file up on the transcript repository.

Can you submit a PR here to fill in more information (including a
signed attestation):
https://github.com/ZcashFoundation/powersoftau-attestations/tree/master/0003

Cody Burns is going next.

Sean

On Sat, Nov 11, 2017 at 1:35 PM, Jared Tobin <jared at jtobin.io> wrote:
>
> Hi all, here's my report:
>
> Powers of Tau Operational Writeup
> =================================
>
> Round: 3
> Date: 2017-11-12
> Name: Jared Tobin
> Location: Auckland, NZ
>
> Challenge:
> e712fa22f1d027a0b4ce3ef698f26d5cab07c3380e4c24a479a914c85617fd1a2960b386cceb5c94718979010a1b7ed8b6145da872f0744e06503bd664fe7283
> Response:
> cb48afb82ab4c476ae741633c3eb6643e7700dc7b2b4701af91e3cc932270b96c375e5f3a5c20c96fac6c9b40a5bba6c956d66f223f090c545c277aa05427757
>
> Preparation Steps
> =================
>
> Being somewhat pressed for time and hardware, I recruited several
> geographically-distributed volunteers that I know well and trust
> completely to help me out.  In the end, the following volunteers were
> able to get back to me in time:
>
> * Shawn Tobin (RSA Canada)
> * Fredrik Harryson (Parity Technologies)
> * Jason Forbes (Kraken Sonar Systems)
>
> I set up a private Keybase team with the above volunteers, distributed
> the challenge to them over KBFS, and gave them instructions over the
> team chat on how to proceed.  Each was to add entropy and compute the
> response locally using whatever mechanisms they preferred (report not
> required), then return their response/hash pairs to me over KBFS.  Each
> member was to use the code in Sean's powersoftau repository as of commit
> 9e1553c437183540392a7231d0788318a19b18a3 to perform the computation.
>
> Procedure
> =========
>
> I computed a response locally in rather mundane fashion using rustc
> 1.21.0 on an early-2015 model Macbook Air running Sierra.  Eventually
> the volunteers managed to upload their response/hash pairs to KBFS, and
> I randomly selected one of the resulting four responses to submit for my
> piece of the MPC.
>
> I uploaded the resulting response via the handy app Sean provided me with.
>
> Side channel defences
> =====================
>
> I used broad geographical distribution and randomness to mitigate the
> possibility of successful side channel attacks.  Shawn was located in
> Vancouver, Canada, Fredrik was located in Malmö, Sweden, and Jason was
> located in St. John's, Canada.
>
> I selected the response to upload by pre-determining a correspondence
> between names and numbers, and then walking outside and asking the first
> stranger I saw to pick a number between one and four.
>
> - jared
>
>
> On Sat, Nov 11, 2017 at 12:25:33AM +0000, Jason Davies via zapps-wg wrote:
>> Hi all,
>>
>> Here is my report:
>>
>> Powers of Tau Operational Writeup
>> =================================
>>
>> Round: 2
>> Date: 2017-11-10
>> Name: Jason Davies
>> Location: London, UK
>>
>> Challenge: 467bc84f6eb98ff956eaf12a1b7ef4dc0aff1093c7a0d5c1dfbdb85bbfffb20a43965d0daefee3fec6c1a47af69100e117b44b74371824ac8af1e33b6f91add5
>> Response: 2f728af894524f55bda7a3e2c2e2db6a57a992811e90ed57456d62aead5106cdc5c97c86532d14b5185cc74d169f1b0c2c0ef1e582231ffa7936da55047c0cb2
>>
>> Preparation Steps
>> =================
>>
>> Git repository: https://github.com/ebfull/powersoftau
>> Commit hash: 9e1553c437183540392a7231d0788318a19b18a3
>> Compiler: rustc 1.23.0-nightly (d6b06c63a 2017-11-09)
>> Build: cargo build --release --features=u128-support
>> b2sum(./target/release/compute): be42f68b07c5c857bb6561a9ac2967d671ef412a71c87c2fb31776a6ab38c756736de66e554553021e129ecab45d922092873df8b71bd9a775ec05f189485198
>>
>> I used a brand new 16GB USB stick and loaded ubuntu-17.04-desktop-amd64.iso; b2sum: 6a1c975b25b4e7f2dbf4fda84fe8b5de3ed6f4532b8c4f17e533ed11a0a8b5b9ad9fb83e8e4b89447c3a427be73f77a5f7c71b7f733fcc4bebf346e9c5c0de43.
>>
>> I reformatted a second brand new 16GB USB stick to ext4, then copied the
>> `challenge` file and the `target/release/compute` binary.
>>
>> Sidechannel Defences
>> ====================
>>
>> First of all, I lined a large cardboard box with aluminium foil in order to
>> make a rudimentary faraday cage.  Then, I assembled an airgap compute node
>> using some relatively cheap parts, putting them all inside the box:
>>
>> * Motherboard: Asus H81 Pro BTC (no radio, bluetooth or speakers AFAIK)
>> * CPU: Intel G1840
>> * Ram: 2x cheap 1GB sticks
>> * PSU: EVGA SuperNOVA 1300 G2
>> * Monitor: old Dell TFT display
>> * Keyboard: generic USB keyboard
>>
>> No other peripherals or cables were connected.  I placed the compute node in my
>> cellar (~6ft below ground level) and I remained with the node during the entire
>> time it was computing, without using any other devices in the vicinity (no
>> mobile phone etc.)  The only cables coming out of the box were the two power
>> cables, one for the PSU and one for the monitor.
>>
>> Image: https://pbs.twimg.com/media/DOT55KUXUAEV44-.jpg:large
>>
>> Procedure
>> =========
>>
>> I booted the node, with "Try Ubuntu" (Live CD mode).  Then, I inserted the
>> challenge USB stick and ran `./compute` in the USB media directory, entering
>> some additional entropy as requested by typing randomly on the keyboard.  The
>> box lid was only partially opened to allow use of the keyboard and to view the
>> monitor at this point.  After 60 minutes had passed, I looked inside the lid
>> and saw that the computation had completed, so I wrote down the BLAKE2b hash,
>> and unmounted and removed the USB stick, and then powered the node down.
>>
>> Postprocessing
>> ==============
>>
>> I took the USB stick and transferred the response file to my laptop, and then
>> uploaded it using the laptop to S3 via Sean Bowe's transcript site.
>>
>> I did not destroy the compute node but I'm unlikely to use it or plug it in for
>> some time.
>> --
>> Jason Davies, https://www.jasondavies.com
>>
>
>
>>
>>
>> > On 10 Nov 2017, at 22:11, Sean Bowe via zapps-wg <zapps-wg at lists.z.cash.foundation> wrote:
>> >
>> > Thanks Andrew! That's a great start.
>> >
>> > Now it's Jason Davies' turn.
>> >
>> > The entire transcript will appear here throughout the process:
>> >
>> > https://powersoftau-transcript.s3-us-west-2.amazonaws.com/index.html
>> >
>> > We can make a more formal announcement once we're in the groove and
>> > everything looks good. We're getting a repo up with attestations soon
>> > also.
>> >
>> > Sean
>> >
>> > On Fri, Nov 10, 2017 at 12:53 PM, Andrew Miller <soc1024 at illinois.edu> wrote:
>> >> OK, I'll go first. Below is my report:
>> >>
>> >> Powers of Tau Operational writeup
>> >> =================================
>> >> Round: 1
>> >> Date: 2011-11-10
>> >> Name: Andrew Miller
>> >> Location: Champaign, Illinois
>> >>
>> >> Challenge: (genesis)
>> >> ce00f2100dd876fdff8dd824f55307bcb72d724f29ff20b9e0760f3a65e5588a65eaed57cbc61697111ae1f4cc7da2e62a85311c2ae683a041fb872b891c68dc
>> >> Response:
>> >> 15729e0edc4201dc5ee6241437d926f614cb4214ff1b9c6fbd73daf401639f7a4238cf04bc94edac9f2ad037003daab9a4408ba7c62a4413dc2a0ddd683bd719
>> >> ./response-2017-11-10-amiller
>> >>
>> >> Preparation steps
>> >> =================
>> >> I used Sean’s powersoftau rust repo, commit
>> >> 9e1553c437183540392a7231d0788318a19b18a3
>> >>
>> >> I followed instructions online for building portable rust binaries,
>> >> and so I ran
>> >> ```
>> >> cargo build --target=x86_64-unknown-linux-musl --release
>> >> --features=u128-support --bin=compute
>> >> ```
>> >>
>> >> Compiler: rustc 1.23.0-nightly (02004ef78 2017-11-08)
>> >>
>> >> I copied the resulting binary to a freshly formatted USB stick I had.
>> >>
>> >> b2sum:
>> >> 9059a0a64f5021c36df630ca48ac40674862b2fea14f4843ff2150256b95162ac4d6d1621d2dd3f5d0d1c604ad8e581c0ff449d2449140380eab075a9b83c960
>> >> ./target/x86_64-unknown-linux-musl/release/compute
>> >>
>> >> I also rummaged through my shelf of several USB sticks, and found one
>> >> that happened to be a Linux Mint 18 USB bootable disk, so I used that
>> >> for my operating system.
>> >>
>> >> Sidechannel defenses
>> >> ====================
>> >> I used an airgap compute node, a Dell Inspiron that I’ve had for about
>> >> a year now (Actually this is a computer I bought last year for
>> >> dress-rehearsals in the Zcash Sprout param generation ceremony).
>> >>
>> >> I unplugged all the computer’s hard drives, and detached its
>> >> wifi/bluetooth radios. I booted the computer from the Linux Mint
>> >> livecd usb stick, and then also copied the binaries into RAM. The
>> >> compute node was located in my bedroom, and I attended it for the ~1hr
>> >> duration of the compute process.
>> >>
>> >> Image: https://pbs.twimg.com/media/DOSZz4FXkAEKC7N.jpg:large
>> >>
>> >> Postprocessing
>> >> ==============
>> >> After compute was finished, I took a cell phone picture of the blake2b
>> >> hash of the response. I then copied the response file to the USB stick
>> >> containing the binaries, and then I unplugged the compute node. Using
>> >> my personal laptop, I posted the blake2b hash to the #mpc chat and
>> >> uploaded the response file to s3.
>> >>
>> >> The repsonse file is hosted here for now, though I expect we'll
>> >> mirror it elsewhere later:
>> >> https://s3.amazonaws.com/socrates1024_a/response-2017-11-10-amiller
>> >>
>> >> I did not destroy the compute node and do plan to use it again,
>> >> although I'm going to leave it unplugged for several days.
>> >>
>> >> On Wed, Nov 8, 2017 at 10:19 PM, Sean Bowe <sean at z.cash> wrote:
>> >>> Note that the `response` file contains a hash of the `challenge` file
>> >>> that was used as input for the compute tool. As a result, only the
>> >>> hashes of the `response` files need to be published; a hash chain is
>> >>> formed through all participants. The initial challenge file is
>> >>> deterministic. (You can use the `new` tool on the repository to
>> >>> construct it.)
>> >>>
>> >>> The initial challenge file has BLAKE2b hash:
>> >>>
>> >>> ce00f2100dd876fdff8dd824f55307bcb72d724f29ff20b9e0760f3a65e5588a65eaed57cbc61697111ae1f4cc7da2e62a85311c2ae683a041fb872b891c68dc
>> >>>
>> >>> It doesn't hurt to post hashes of everything though. Hash all the things.
>> >>>
>> >>> Sean
>> >>>
>> >>> On Wed, Nov 8, 2017 at 4:51 PM, Andrew Miller <soc1024 at illinois.edu> wrote:
>> >>>> Thanks Sean!
>> >>>>
>> >>>> My idea is to use an ad hoc and publicly visible process. "Get in
>> >>>> contact with [sean]" could be as simple as posting in public to this
>> >>>> thread. Unless we're overrun by trolls, a public mailing list can be
>> >>>> an informal way to agree on who goes next. Whoever posts and says "Me,
>> >>>> me! I'd like to go next", should, by convention, go next. Any
>> >>>> aberrations (parties taking too long or dropping out, posting invalid
>> >>>> data, etc., can be dealt with as needed).
>> >>>>
>> >>>> I believe it's also the case that
>> >>>> a) The "response" file from each person is roughly the same as the
>> >>>> "challenge" file for the next participant, and
>> >>>> b) The response/challenge files are safe to be published at any time,
>> >>>> not private at all.
>> >>>> So, by convention, we should post the hashes of those files here right
>> >>>> away, and make a best effort to mirror them publicly (each one is like
>> >>>> a gigabyte, I think).
>> >>>>
>> >>>> What does the initial challenge file consist of? Could you post the
>> >>>> hash of it here?
>> >>>>
>> >>>> Cheers,
>> >>>>
>> >>>> On Wed, Nov 8, 2017 at 3:04 PM, Sean Bowe via zapps-wg
>> >>>> <zapps-wg at lists.z.cash.foundation> wrote:
>> >>>>> Ariel Gabizon, Ian Miers and I have just published a new paper detailing a
>> >>>>> multi-party computation (MPC) protocol for constructing zk-SNARK public
>> >>>>> parameters.
>> >>>>>
>> >>>>> https://eprint.iacr.org/2017/1050
>> >>>>>
>> >>>>> The highlights are:
>> >>>>>
>> >>>>> * It allows for a single, gigantic ceremony to take place for all possible
>> >>>>> zk-SNARK circuits within a given size bound. The results of this ceremony
>> >>>>> are partial zk-SNARK parameters for the entire community. We call this
>> >>>>> communal ceremony the Powers of Tau.
>> >>>>> * If you want to use zk-SNARKs in your protocols, you still have to do an
>> >>>>> MPC for your circuit. But because of the Powers of Tau ceremony, your
>> >>>>> ceremony is much cheaper to perform and the costs per-participant scale
>> >>>>> linearly with respect to the circuit complexity.
>> >>>>> * The best part is that the Powers of Tau and these circuit-specific MPCs
>> >>>>> can scale to hundreds/thousands of participants. As the number of
>> >>>>> participants grows, it becomes unrealistic that all of them could be
>> >>>>> compromised.
>> >>>>>
>> >>>>> So, let's do the Powers of Tau ceremony! The Zcash Foundation is excited to
>> >>>>> participate in the process. The Zcash Company is particularly excited in
>> >>>>> starting soon because we want to leverage it for our next MPC for the
>> >>>>> Sapling upgrade of Zcash.
>> >>>>>
>> >>>>> The MPC protocol for this ceremony only requires that one participant
>> >>>>> successfully destroy the secret randomness they sample during their part. We
>> >>>>> intend to give participants total flexibility in deciding how to
>> >>>>> participate; we don't mind what software, hardware or OS you use.
>> >>>>>
>> >>>>> I have written some Rust software for participants to run:
>> >>>>>
>> >>>>> https://github.com/ebfull/powersoftau
>> >>>>>
>> >>>>> In order to simplify auditing, I won't be making any more changes to the
>> >>>>> code unless absolutely necessary. You don't have to use this software, but
>> >>>>> there are no alternative implementations at this time. I think it should be
>> >>>>> feasible to write a C version of the code using the RELIC toolkit, which has
>> >>>>> implemented BLS12-381. I am very confident in the Rust code, though, and I
>> >>>>> believe in its stability/correctness.
>> >>>>>
>> >>>>> I have some opinions about the ceremony:
>> >>>>>
>> >>>>> 1. I disagree with processes that don't improve security of the ceremony.
>> >>>>> Having a small surface area of code and process increases the chance that
>> >>>>> bugs will be discovered by auditors because there are fewer things that can
>> >>>>> go wrong. Remember that there is already quite a bit for the public to
>> >>>>> check: the transcript correctness, the code correctness, the randomness
>> >>>>> beacon, the cryptographic proof, code dependencies, etc.
>> >>>>> 2. It needs to start soon so that it can be useful for the Sapling MPC.
>> >>>>> 3. It needs to have lots of reputable participants by the time we start the
>> >>>>> Sapling MPC.
>> >>>>>
>> >>>>> Given the above, I would like to suggest that we start the ceremony now
>> >>>>> using my existing code, which supports circuits up to 2^21 gates. This means
>> >>>>> people would just get in contact with me if they want to participate and
>> >>>>> I'll schedule them in. I'll try to prioritize reputable people, but I'll
>> >>>>> allow pretty much anyone I have time to. Everything that I do is publicly
>> >>>>> verifiable (there is a transcript at the end of the ceremony which people
>> >>>>> can check).
>> >>>>>
>> >>>>> Andrew Miller has a few interesting ideas for a more distributed process for
>> >>>>> scheduling "who goes next" but there are some disadvantages and risks
>> >>>>> involved IMO. In any case, the process can be changed later without
>> >>>>> affecting anything, so I don't see a purpose in delaying the start of the
>> >>>>> ceremony on such things.
>> >>>>>
>> >>>>> I'd like to hear from others about this plan so we can begin soon!
>> >>>>>
>> >>>>> Sean Bowe
>> >>>>> Zcash Company
>> >>>>
>> >>>>
>> >>>>
>> >>>> --
>> >>>> Andrew Miller
>> >>>> University of Illinois at Urbana-Champaign
>> >>
>> >>
>> >>
>> >> --
>> >> Andrew Miller
>> >> University of Illinois at Urbana-Champaign
>>
>