-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Powers of Tau Operational writeup
=================================

Round: 7
Date: 2017-11-16
Name: Eric L. Stromberg
Location: San Francisco area, US

Challenge: 2ae068fbe1a9d0e070844047f3032432e86b822f593da3fcd6fc0ee8bed2f30caac587a1d5e68ea6fcdcf1a40213de7d41ded05cf9be934e4c6d617e201caa1a
Response: 1ad851c65b4fcf3ca0bce6b366c40c48b65f611044731faf2b5fc90f987eda3f3240ea25c555e516ff73de2855369fd2da77a7055529b6f72ac3225b07fd8585 

Preparation steps
=================

UBUNTU

Build VM & compute node OS from: ubuntu-16.04.3-desktop-amd64.iso
SHA256: 1384ac8f2c2a6479ba2a9cbe90a585618834560c477a699a4a7ebe7b5345ddc1  

Build VM, create compute binary:
Created new Ubuntu 16.04.3 VM from ISO
Followed instructions indicated in repository Readme to build “compute” binary
https://github.com/ebfull/powersoftau [commit 9e1553c437183540392a7231d0788318a19b18a3]
Formatted fresh 8GB USB stick, copied compute binary to it.
BLAKE2b-64 (./compute) = 7af5d31bbb215eab40753043523790483cdda67aef1d6e317f4269fb042dbc8608feaa0db8d17df82bef28f021509871635a56052de1370f4b90dc6322a8a962

Setup minimal compute node (ASUS 1015E laptop, 2GB RAM, Celeron 847, 320GB HDD):
Flash BIOS with latest (2013/05/23) from: http://dlcdnet.asus.com/pub/ASUS/nb/1015E/1015EAS304.zip
SHA256: 9ee3256bbc7116388a6c5079773d8ac28471f0cfbb2db8784e403c36c3bbd9bb  
Install ubuntu 16.04.3 from DVD: erase and reinstall, no network, no updates.
Copy compute binary and challenge file from USB stick.

MAC OSX

Build VM, create compute binary:
Used “Install macOS Sierra 10.12.app” from Apple.
Followed same steps as above to create “compute” binary.
BLAKE2b-64 (./compute) = 88565a9e84c9ee69818e78909b7f6b05ef46a88780b8378d44a037be7e8fd50c7c601e8340455be2ed9e703095baf88883f9104fded0086576c9c43c36fb6bf9

Installed MacOS on external SSD drive with “Install macOS High Sierra 10.13.0.app” from Apple.
To be used as boot image for MacBook Pro laptop, second compute node  (Internal disk is encrypted).
Copied compute binary and challenge to SSD drive.

Workspace preparation:

An interior closet containing a heavy gauge steal gun safe was lined with multiple layers of foil shielding to allow access to the compute node keyboard with the safe door open and still limit EM leakage.  Compute node, USB stick and 8 hexadecimal dice in a dice box placed in safe, with a power cord routed through the safe door opening: https://www.dropbox.com/s/ysfmhre0cjkhe1g/tinfoilsafe.jpeg?dl=0

Procedure
=========

For each of 3 compute runs, door to closet closed to effectively create a faraday room with safe containing the compute node (laptop) inside.  Safe door open to allow access to keyboard and screen.  Ran ./compute and when prompted, provided 64 bytes of entropy with 4 rolls of 8 hexadecimal dice in a box used to both randomize them and to order them unambiguously.  Once compute process was underway, closed and locked safe until completion of the compute process.

Sidechannel defenses
====================

The ASUS compute node is a 4 year old device, ordered by me through Amazon with 2-day shipping, with Ubuntu 12.04 factory installed; reimaged with w/16.04.3 for this exercise.  Was previously turned on once to set it up / verify and not otherwise used or connected to any network.  Node has been air gapped at all times since purchase.  The MAC compute node is a personal device and well used.  The Mac OS image created on an external drive for this exercise was never network connected and erased immediately afterwards.  The internal drive is encrypted and was not accessible to the boot image used.  All 3 production compute runs were performed in a rural area with no other structures or public roads within 100 yards in any direction.  The compute nodes were operated in a heavy gun safe within an interior closet shielded with foil to control EM leakage even when the safe door was open for keyboard access.  The safe was kept closed and locked during computation.  One of 3 results was randomly selected for submission without attribution.

Postprocessing
==============

ASUS: copied hash and response file to USB stick.  Battery removed from compute node.  Copied hash and response to personal laptop then securely erased USB and overwrote with random data.  I did not destroy the node, but it will remain unpowered and locked in a safe for at least one month and will either never be used again (and be destroyed) or will be used only as an offline signing device, securely stored and never connected to any network. MAC: after each of the 2 compute runs, copied hash onto SSD drive.  Powered off Mac.  Copied hash and response files to personal laptop then securely erased SSD (boot drive) and overwrote with random data.  Will continue to use SSD and Mac for other purposes.  A roll of hexadecimal dice was used to select 1 of the 3 response files.  50% probability given to result generated on the ASUS node and 25% probability given to each result from the MAC node.  The randomly selected result was verified and submitted - the hash of which is above.

- --
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEE8uf9gsaoeapQAjniTNm5XypzZrQFAloOadEACgkQTNm5Xypz
ZrQg0w/9E1xf3opRjkowv1fVTLRg+LdPaA2mUVh0XDiAmHs4os+eWv9Q3ZUTnCk7
wk5vlDxAgeva2pHVyo+39sIV+ciSbJ2S2nu1dZzlOEFvQWbKII3TdvWCVArCigWd
lfkqR/94Rj1Cv7kapAje4MkyRf8CXhcNcrq7LrWhQUdjUiwObX110ZsqPf3OPlBf
B7s582WD+m5GzN3bdJqY/QWsr9jzrEJT+p4XflcRCnAbtRXdNiz3egLK5gnoMxjn
uNBJFjmWx7iwVNRxmKVPPLmjILwdVg+NC8JLTTjjcY8nt/JHKC/kny3iEc6c7hhg
eMVziWuYpGu4r46FGiyHDO5Ls6ZC54LqrMFWxxa7ZwzKYUeeIlbziOld+XagQqDe
fHIhixGiXIYD/Nwdmv64NSYkUx0eaorJ0mYmZA7qu4JKNxNvgDJu9F/SLWgIzM2o
w/dIIEzNGhsx3FjYG8LrERzTD8QHe7zRIV8wG+0K9zPAA3Lz2w9qav3kXgx3YuiG
Odls/1oscTtM31UK6PhsOJac0hjwBhalJTrYHK1TD/Ac3bXrAGW1ZnaINQjquNys
TdTlSlgyjg9EXDyWspoWqSq9DTj6WcgvCtbpXmfE1Z1jaGwFpvKD9f3P5lJEzN1U
GUq87nuiAx65N6JnFr9+kgmldor8tcjg/ajYif0wF2nkhV/b7ZM=
=B/su
-----END PGP SIGNATURE-----

Attachment: report.asc
Description: Binary data


On Thu, Nov 16, 2017 at 8:21 PM, Hudson Jameson via zapps-wg
<zapps...@lists.z.cash.foundation> wrote:
I have finished the report and made a PR in the attestations repo:
https://github.com/ZcashFoundation/powersoftau-attestations/pull/5

I also made a fun Imgur album of the adventure: https://imgur.com/a/2rUDz

Please note that there are 2 names for round 6, Hudson Jameson and
Steven Schroeder.

Hudson Jameson


On Nov 13, 2017, at 11:38 PM, Kobi Gurkan via zapps-wg <zapps...@lists.z.cash.foundation> wrote:

Signed PGP part
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





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>

Attachment: signature.asc
Description: Message signed with OpenPGP

Reply via email to