Oh, I see! I think it's a difference between how b2sum and compute print the hashes (compute has groups while b2sum not?) ᐧ
On Tue, Nov 14, 2017 at 6:23 PM, Sean Bowe <s...@z.cash> wrote: > Kobi, > > Thanks! I've gotten a response file with the following hash: > > f01f2679613a75ef09f94f588cc3253962c49c9129b174d9145336011ada > 960e29c8c91a21314705ebdbd081e526bd4d738447385b95e95d5043764786f01441 > > However, in your attestation you wrote: > > f01f2679613a75ef9f94f588cc3253962c49c9129b174d914533611ada96 > e29c8c91a2131475ebdbd081e526bd4d738447385b95e95d5043764786f01441 > > It's three minor transcription errors of the same kind (omission of a > zero), so I think we can safely ignore it. > > I've verified the response file, and thus accepted it into the transcript. > :) > > Sean > > > On Tue, Nov 14, 2017 at 12:38 AM, Kobi Gurkan <k...@qed-it.com> wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA256 >> >> Powers of Tau Operational writeup >> ================================= >> Round: 5 >> Date: 2017-11-13 >> Name: Kobi Gurkan >> Location: Netanya, Israel >> >> Challenge (blake2b, sha256): >> 658a6f81174a3ba72abc3a549483b4891d5be2351c6d1965c5a0bd20f91ea654c2e33c85109401cbd418d474a8762a41e1b62034251e118958d3ff9b8c74 >> 3f8938fdaa30ea4232939629d722ed0d1a40c5bd4268cbbf5bb6bbbbe34ac802 >> >> Response (blake2b): >> f01f2679613a75ef9f94f588cc3253962c49c9129b174d914533611ada96e29c8c91a2131475ebdbd081e526bd4d738447385b95e95d5043764786f01441 >> >> Preparation steps >> ================= >> I built a docker image based on Andrew Miller's Dockerfile from: >> https://hub.docker.com/r/socrates1024/powersoftau/~/dockerfile/. The >> Dockerfile I used also verified that rustup.sh has a sha256 hash of value >> "22aa1f7f4c4b9be99a9d7e13ad45b2aec6714165a0578dd5ef81ca11f55ea24e". >> Nevertheless, building the image using the Dockerfile produced the "compute" >> binary based on Sean’s powersoftau rust repo, commit >> 9e1553c437183540392a7231d0788318a19b18a3 with the same sha256 hash reported >> by Andrew and others - >> 922b2e0a59841ecdaba7b4953d8c67e62b74b8f52f968624cff664dc086da93a. >> >> I burned an Ubuntu 16.04.03 live cd to a blank DVD and the compute binary to >> another DVD. >> >> I then took an old Xtreamer Ultra HTPC that I disassembled, removed the hard >> disk and removed the RAM stick for about 2 minutes (Image: >> https://pbs.twimg.com/media/DOkcOtqWsAAylKI.jpg:large). >> The relevant technical specification of the PC are: >> - - Samsung 4GB DDR3 (SO-DIMM/204pin/DDR3-1333/PC3-10600) >> - - Intel Atom D525 (dual-core, 1.8 GHz) >> >> I disconnected the electronic devices near the PC besides a Dell U2414H >> monitor connected by HDMI, a Microsoft Natural Ergonomic Keyboard 4000 and a >> Microsoft Comfort Mouse 3000, connected by USB. >> >> After booting the live cd, I verified its MD5 and found the same one that >> appear on the Ubuntu web-site (http://releases.ubuntu.com/16.04.3/MD5SUMS): >> 0d9fe8e1ea408a5895cbbe3431989295 *ubuntu-16.04.3-desktop-amd64.iso (Image: >> https://pbs.twimg.com/media/DOkcWy_W0AUu8a1.jpg:large) >> >> I also re-verified the hash of the compute binary from the second DVD and >> copied both the challenge and the compute binary to RAM (Image: >> https://pbs.twimg.com/media/DOkcg2_X0AE0NVU.jpg:large). >> >> I prepared an external hard-drive I had for extraction of the report later >> on. >> >> Sidechannel defenses >> ==================== >> The PC I used was bought a few years ago. I disconnected the hard disk and >> all peripherals besides monitor, keyboard and mouse. I disconnected >> electronic devices around the PC such that the room had only the devices >> mentioned connected. I was in the house the entire time (although asleep). >> >> Postprocessing >> ============== >> After compute finished its operation, I took a photo of the blake2b and >> sha256 hashes of the resulting response (Image: >> https://pbs.twimg.com/media/DOkcae4W4AAhBG7.jpg:large). Then, I copied the >> file to the USB external hard drive and then to my laptop. >> I verified on my laptop that the sha256 hash is the same one calculated on >> the PC (laptop) and ran verify_transform. >> I disconnected the PC from power and physically removed the RAM stick. I >> don't plan to use this computer in the coming weeks. >> >> My upload link expired before I could upload the response, so I uploaded it >> to google drive: >> https://drive.google.com/file/d/1K7c0zbt0quZmAAMNiMPVjoE0WPn13Zh3/view?usp=sharing >> -----BEGIN PGP SIGNATURE----- >> Version: Mailvelope v2.0.0 >> Comment: https://www.mailvelope.com >> >> wsFcBAEBCAAQBQJaCo55CRBEcm3jN1yF3gAAFVIQAKBR+Tj+KUsj4pZt/iRF >> Ltgy5Yq1X3wNdDHkgad2mrUO2KGdD+1i1O+Wj+IaURhis5ZiGhB3G460/kVc >> +3XijxDO3HIaZaBPwCr8b1vjbwIUGW0C7E66XzJ7EYkfZJ+i2FAd83gfVrDl >> tLk2VAo/S8S4vpklkED2sNYT59QDO59cLxJ1TzxsxSbKzyDxtJt6Lc82Vus4 >> VbRM9SzUzb4URQ3fBHxQWM0oyr06KxUdS95QOw1uO5icdEzSPcnzljihDRY0 >> U5ogEhDOs+nKHPCsfyT2SSW+ty/jXEitWpy2R4w8WS/E2XHZKhEIpOtSLLBd >> Txqa3qqqeyfrb1Q7sfUYzYEEjhA+5J0pRe76Uyu0qyNbkXfyw1oa7c7y+4cj >> VHGJtbDpksrul69g+XQ6yYT+dUVN9yS2dN80Z014bX10qnJjeGjX2NLPqTex >> hdEKm7UfalFVutAm2jKoerCm2YdKpVaSkpnpPu4ZKBr0UzNNHkGpR73deoKr >> F2Dh31+M721DTFY1nHszUFhohcS0dCmW5i2gx32oN6UZpdewHv9jmpAioYIX >> Da+Ybl8E3pWYAIOTcBOGThknKdrSqmXMsUJK+i2ZyyDS8COgmZ0XuCq7kNWI >> RsU4WZRnitHn6mnDU92w+7kh5Ayl+pSgns1mFe9Kp2LqmAePf5+cvJtL8nlR >> LHES >> =r6L2 >> -----END PGP SIGNATURE----- >> >> >> ᐧ >> >> On Mon, Nov 13, 2017 at 6:53 AM, Sean Bowe via zapps-wg < >> zapps...@lists.z.cash.foundation> wrote: >> >>> Thanks Matt, that's really cool. I've verified your contribution and >>> it's now in the transcript. >>> >>> I've put some minimal information here about your contribution: >>> >>> https://github.com/ZcashFoundation/powersoftau-attestations/ >>> tree/master/0004 >>> >>> Would you mind submitting a PR (along with a signed attestation if you >>> can)? >>> >>> Kobi wished to go next but won't be available for a little while. Then >>> someone else (who hasn't posted "i'm going next" on the mailing list >>> yet) indicated they would like to go. >>> >>> Sean >>> >>> On Sun, Nov 12, 2017 at 7:05 PM, Matt Drollette via zapps-wg >>> <zapps...@lists.z.cash.foundation> wrote: >>> > Powers of Tau Operational writeup >>> > ================================= >>> > >>> > Round: 4 >>> > Date: 2017-11-12 >>> > Name: Matt Drollette >>> > Location: Dallas, Texas >>> > >>> > Challenge: >>> > 9b80a6140d42bd234fbe43eea542296df8bcb4c834ea5d0a16a194964b72 >>> fd11a6ee9efae9364eb74f99bb4471e7fb4ac9cb2bb3aa8e03fe22c6279a104f367b >>> > >>> > Response: >>> > 53b6dc5a91d04c3000037cbc4f6f4bc9e9daf9448a41f997746b156c643a >>> 84f481c49bf7dadce388b3c9e8c147f94c12c5dacb5350a54e112ee45f57ffd8f34c >>> > >>> > >>> > Preparation steps >>> > ================= >>> > >>> > I noticed most participants were taking on a significant >>> responsibility in >>> > securing their own hardware and infrastructure in order to participate >>> in >>> > this >>> > process. I took a different approach in that I wanted to leverage the >>> > security >>> > work done by people much more qualified than myself. I therefore used >>> Google >>> > Cloud Platform to generate my response (https://cloud.google.com/secu >>> rity/). >>> > >>> > First, I created a new GCP project under a gmail account not belonging >>> to >>> > any >>> > other organizations and configured with Advanced Protection >>> > (https://landing.google.com/advancedprotection/). >>> > >>> > Next, I created a Compute Instance with an external IP to serve as the >>> > bastion >>> > for external network access and collecting the responses. >>> > >>> > I then created three compute instances in three different regions >>> having >>> > three >>> > different instance types. Each instance was running Google's >>> > Container-Optimized >>> > OS (https://cloud.google.com/container-optimized-os/docs/concep >>> ts/security) >>> > and >>> > did not have an external IP address. >>> > >>> > Next, on the bastion I built a Docker image containing the compute >>> binary >>> > built >>> > from https://github.com/ebfull/powersoftau at commit >>> > 9e1553c437183540392a7231d0788318a19b18a3 >>> > >>> > I downloaded the challenge file to the bastion host and then >>> transferred it >>> > to >>> > each compute instance along with the compute Docker image via scp over >>> the >>> > internal network. I verified the sha256 hash of each challenge and >>> compute >>> > binary on each instance and then began the computation using different >>> > random >>> > inputs for each process. >>> > >>> > ``` >>> > bastion >>> > 480c27457c467362a1d3dd3d972844e1230abde236f4d153d80938ab7ec19f7d >>> challenge >>> > 4952c8b4e8d3e75ded8fafa28bffb4082e26732f17ec8176c7cd26591adaf93e >>> > powersoftau.docker >>> > 922b2e0a59841ecdaba7b4953d8c67e62b74b8f52f968624cff664dc086da93a >>> > /powersoftau/target/x86_64-unknown-linux-musl/release/compute >>> > >>> > instance-1 >>> > 480c27457c467362a1d3dd3d972844e1230abde236f4d153d80938ab7ec19f7d >>> challenge >>> > 4952c8b4e8d3e75ded8fafa28bffb4082e26732f17ec8176c7cd26591adaf93e >>> > powersoftau.docker >>> > 922b2e0a59841ecdaba7b4953d8c67e62b74b8f52f968624cff664dc086da93a >>> > /powersoftau/target/x86_64-unknown-linux-musl/release/compute >>> > >>> > instance-2 >>> > 480c27457c467362a1d3dd3d972844e1230abde236f4d153d80938ab7ec19f7d >>> challenge >>> > 4952c8b4e8d3e75ded8fafa28bffb4082e26732f17ec8176c7cd26591adaf93e >>> > powersoftau.docker >>> > 922b2e0a59841ecdaba7b4953d8c67e62b74b8f52f968624cff664dc086da93a >>> > /powersoftau/target/x86_64-unknown-linux-musl/release/compute >>> > >>> > instance-3 >>> > 480c27457c467362a1d3dd3d972844e1230abde236f4d153d80938ab7ec19f7d >>> challenge >>> > 4952c8b4e8d3e75ded8fafa28bffb4082e26732f17ec8176c7cd26591adaf93e >>> > powersoftau.docker >>> > 922b2e0a59841ecdaba7b4953d8c67e62b74b8f52f968624cff664dc086da93a >>> > /powersoftau/target/x86_64-unknown-linux-musl/release/compute >>> > ``` >>> > >>> > >>> > Sidechannel defenses >>> > ==================== >>> > >>> > The scale of GCP and sheer number of compute instances makes a targeted >>> > sidechannel attack practically impossible. Also, Google takes great >>> care in >>> > preventing known attack methods >>> > (https://cloudplatform.googleblog.com/2017/01/7-ways-we-hard >>> en-our-KVM-hypervisor-at-Google-Cloud-security-in-plaintext.html). >>> > >>> > In addition to Google's security practices, I also ran multiple compute >>> > instances in multiple regions computing responses on the same >>> challenge file >>> > at >>> > the same time. I then selected only one of these responses at random to >>> > submit >>> > and destroyed the others. I do not know which node computed the >>> response >>> > that I >>> > submitted. >>> > >>> > >>> > Postprocessing >>> > ============== >>> > >>> > Once the responses were computed on each instance, I recorded the >>> hashes of >>> > each >>> > response file and transferred all 3 files back to the bastion host and >>> > deleted >>> > the 3 compute instances. I did not record which instance computed which >>> > response. I then selected one of the 3 response files by dice roll and >>> > submitted >>> > its hash to the mailing list and uploaded the file to S3. I then >>> deleted the >>> > bastion compute instance and deleted the entire GCP project. >>> > >>> > >>> > --- >>> > Matt Drollette >>> > >>> > On Sun, Nov 12, 2017 at 4:45 PM, Sean Bowe <s...@z.cash> wrote: >>> >> >>> >> Unfortunately, Cody had some problems and needs to reschedule. Also, >>> >> Kobi doesn't have time right now, so it's Matt's turn! >>> >> >>> >> Sean >>> >> >>> >> On Sun, Nov 12, 2017 at 12:40 PM, Sean Bowe <s...@z.cash> wrote: >>> >> > Cody is going but I haven't heard back in a while. In let's say >>> about >>> >> > five hours if we still don't hear back we'll move on to Kobi and >>> >> > reschedule with Cody later. Matt can go after that! :) >>> >> > >>> >> > Sean >>> >> > >>> >> > On Sat, Nov 11, 2017 at 8:24 PM, Matt Drollette via zapps-wg >>> >> > <zapps...@lists.z.cash.foundation> wrote: >>> >> >> I'd like to be added to the queue. Happy to go after Cody unless >>> there >>> >> >> are >>> >> >> others already lined up. >>> >> >> >>> >> >> >>> >> >> --- >>> >> >> Matt Drollette >>> >> >> >>> >> >> On Sat, Nov 11, 2017 at 4:31 PM, Sean Bowe via zapps-wg >>> >> >> <zapps...@lists.z.cash.foundation> wrote: >>> >> >>> >>> >> >>> 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 <ja...@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: >>> >> >>> > >>> >> >>> > >>> >> >>> > e712fa22f1d027a0b4ce3ef698f26d5cab07c3380e4c24a479a914c85617 >>> fd1a2960b386cceb5c94718979010a1b7ed8b6145da872f0744e06503bd664fe7283 >>> >> >>> > Response: >>> >> >>> > >>> >> >>> > >>> >> >>> > cb48afb82ab4c476ae741633c3eb6643e7700dc7b2b4701af91e3cc93227 >>> 0b96c375e5f3a5c20c96fac6c9b40a5bba6c956d66f223f090c545c277aa05427757 >>> >> >>> > >>> >> >>> > 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: >>> >> >>> >> >>> >> >>> >> 467bc84f6eb98ff956eaf12a1b7ef4dc0aff1093c7a0d5c1dfbdb85bbfff >>> b20a43965d0daefee3fec6c1a47af69100e117b44b74371824ac8af1e33b6f91add5 >>> >> >>> >> Response: >>> >> >>> >> >>> >> >>> >> 2f728af894524f55bda7a3e2c2e2db6a57a992811e90ed57456d62aead51 >>> 06cdc5c97c86532d14b5185cc74d169f1b0c2c0ef1e582231ffa7936da55047c0cb2 >>> >> >>> >> >>> >> >>> >> 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): >>> >> >>> >> >>> >> >>> >> be42f68b07c5c857bb6561a9ac2967d671ef412a71c87c2fb31776a6ab38 >>> c756736de66e554553021e129ecab45d922092873df8b71bd9a775ec05f189485198 >>> >> >>> >> >>> >> >>> >> I used a brand new 16GB USB stick and loaded >>> >> >>> >> ubuntu-17.04-desktop-amd64.iso; b2sum: >>> >> >>> >> >>> >> >>> >> 6a1c975b25b4e7f2dbf4fda84fe8b5de3ed6f4532b8c4f17e533ed11a0a8 >>> b5b9ad9fb83e8e4b89447c3a427be73f77a5f7c71b7f733fcc4bebf346e9c5c0de43. >>> >> >>> >> >>> >> >>> >> 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/in >>> dex.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) >>> >> >>> >> >> >>> >> >>> >> >> >>> >> >>> >> >> ce00f2100dd876fdff8dd824f55307 >>> bcb72d724f29ff20b9e0760f3a65e5588a65eaed57cbc61697111ae1f4cc >>> 7da2e62a85311c2ae683a041fb872b891c68dc >>> >> >>> >> >> Response: >>> >> >>> >> >> >>> >> >>> >> >> >>> >> >>> >> >> 15729e0edc4201dc5ee6241437d926 >>> f614cb4214ff1b9c6fbd73daf401639f7a4238cf04bc94edac9f2ad03700 >>> 3daab9a4408ba7c62a4413dc2a0ddd683bd719 >>> >> >>> >> >> ./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: >>> >> >>> >> >> >>> >> >>> >> >> >>> >> >>> >> >> 9059a0a64f5021c36df630ca48ac40 >>> 674862b2fea14f4843ff2150256b95162ac4d6d1621d2dd3f5d0d1c604ad >>> 8e581c0ff449d2449140380eab075a9b83c960 >>> >> >>> >> >> ./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/DO >>> SZz4FXkAEKC7N.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/socra >>> tes1024_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: >>> >> >>> >> >>> >>> >> >>> >> >>> >>> >> >>> >> >>> >>> >> >>> >> >>> ce00f2100dd876fdff8dd824f55307 >>> bcb72d724f29ff20b9e0760f3a65e5588a65eaed57cbc61697111ae1f4cc >>> 7da2e62a85311c2ae683a041fb872b891c68dc >>> >> >>> >> >>> >>> >> >>> >> >>> 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 >>> >> >>> >> >>> >> >>> > >>> >> >> >>> >> >> >>> > >>> > >>> >> >> >> >> -- >> ---------- >> Kobi Gurkan >> Core Team Lead >> (+972)-549743033 <+972%2054-974-3033> >> > > -- ---------- Kobi Gurkan Core Team Lead (+972)-549743033 <+972%2054-974-3033>
