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...@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 <soc1...@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 <s...@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 <soc1...@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...@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 >
signature.asc
Description: PGP signature
