Kobi,

Thanks! I've gotten a response file with the following hash:

f01f2679613a75ef09f94f588cc3253962c49c9129b174d9145336011ada960e29c8c91a21314705ebdbd081e526bd4d738447385b95e95d5043764786f01441

However, in your attestation you wrote:

f01f2679613a75ef9f94f588cc3253962c49c9129b174d914533611ada96e29c8c91a2131475ebdbd081e526bd4d738447385b95e95d5043764786f01441

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-
>> 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:
>> >> >>> >> >>>
>> >> >>> >> >>>
>> >> >>> >> >>>
>> >> >>> >> >>> 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>
>

Reply via email to