-----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/
> security/).
> >
> > 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/
> concepts/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-harden-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/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)
> >> >>> >> >>
> >> >>> >> >>
> >> >>> >> >> ce00f2100dd876fdff8dd824f55307bcb72d724f29ff20b9e0760f3a65e5
> 588a65eaed57cbc61697111ae1f4cc7da2e62a85311c2ae683a041fb872b891c68dc
> >> >>> >> >> Response:
> >> >>> >> >>
> >> >>> >> >>
> >> >>> >> >> 15729e0edc4201dc5ee6241437d926f614cb4214ff1b9c6fbd73daf40163
> 9f7a4238cf04bc94edac9f2ad037003daab9a4408ba7c62a4413dc2a0ddd683bd719
> >> >>> >> >> ./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:
> >> >>> >> >>
> >> >>> >> >>
> >> >>> >> >> 9059a0a64f5021c36df630ca48ac40674862b2fea14f4843ff2150256b95
> 162ac4d6d1621d2dd3f5d0d1c604ad8e581c0ff449d2449140380eab075a9b83c960
> >> >>> >> >> ./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:
> >> >>> >> >>>
> >> >>> >> >>>
> >> >>> >> >>>
> >> >>> >> >>> ce00f2100dd876fdff8dd824f55307bcb72d724f29ff20b9e0760f3a65e5
> 588a65eaed57cbc61697111ae1f4cc7da2e62a85311c2ae683a041fb872b891c68dc
> >> >>> >> >>>
> >> >>> >> >>> 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>

Reply via email to