The contribution I got from Jack is corrupted; not the same hash as in Jack's attestation, and one of the points inside of it does not lie on the curve. I suspect data corruption, especially since Jack's internet connection was unreliable.
I have another person scheduled about 7 hours from now, so I may have to move on to that person if I can't get the correct response file. :o I've uploaded the corrupted response file: https://powersoftau-transcript.s3-us-west-2.amazonaws.com/response.15.corrupted and the associated challenge file: https://powersoftau-transcript.s3-us-west-2.amazonaws.com/challenge.15 Sean On Wed, Nov 22, 2017 at 8:09 PM, Sean Bowe <s...@z.cash> wrote: > Thanks! I'm verifying your contribution. > > Note that the `powersoftau` code, unmodified, does not act > determinisically with the random input provided by the user, so: > >> - - Revealing the randomness in the unused response, after the compute node >> had >> been shut down, should make it possible to ascertain that the compute >> binary >> was behaving correctly, by having third parties independently re-compute >> the >> corresponding response file and verify the hash against the one I >> published. > > is not true unless you modified the code so that it does not try to > mix in system randomness as well. > > Sean > > On Wed, Nov 22, 2017 at 6:49 PM, Jack Grigg via zapps-wg > <zapps...@lists.z.cash.foundation> wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA512 >> >> Powers of Tau Operational Writeup >> ================================= >> >> Round: 15 >> Date: 2017-11-22 >> Name: Jack Grigg >> Location: UK >> >> Challenge: >> >> d27e5d6c5a7611f6690443d8a47c6ebd134bc863f05984d9b3d845060a3f036a >> >> >> Response: >> >> 2c052c1f 039810e7 69779017 9943bdb9 >> d00a84fb 25593453 85af3826 1fbe061c >> 4dc79f4e 87da26f4 3202bcf4 3960db16 >> be870511 7f3de50c 8922b502 32a3e126 >> >> >> Procedure >> ========= >> >> 2017-11-18 >> - ---------- >> >> I withdrew cash from an ATM I happened to be passing in London. >> >> 2017-11-19 >> - ---------- >> >> I withdrew more cash from a different ATM. I then drove four hours >> south-west of >> London to my grandmother's farm. She lives in a valley with no cell >> reception, >> and her granite house is well-known in our family for its electromagnetic >> and >> audio shielding properties (ie. WiFi reception sucks beyond the one room the >> router is in, and you can't hear someone calling you from a few rooms away). >> >> On the way down, I stopped in at a shopping center, turning off my phone and >> leaving it in the car. I then purchased: >> >> - - An HP Pavilion Notebook 15 (15-cd054na) >> - I had no device in mind when I entered the store. After browsing the >> available models, I chose this laptop based on a combination of price, >> performance, the use of an AMD chip, and the presence of a DVD burner. >> - I asked the sales assistant if I could choose a laptop at random from >> their >> stock room. The manager confirmed I could not, as it was a secure area. >> I >> asked them to bring out three laptops for me to choose from, which they >> did. >> I flipped two coins to determine which of the three I chose. >> - - Five identical USB drives >> - - A stack of 10 DVD+R discs (which were eventually not used) >> - - A screwdriver set >> - - A soldering iron (which turned out to be unnecessary) >> >> 2017-11-20 >> - ---------- >> >> I unboxed the laptop, and opened it up. I removed the WiFi/Bluetooth chip, >> and >> unplugged the built-in speakers. I then started the laptop and set up the >> default Windows installation, confirming that there was no wireless >> connectivity >> or sound, but the headphone jack still worked. I pried off the screen bezel, >> unplugged the built-in camera and microphone array, and confirmed that they >> both >> no longer worked (the microphone array still showed up as a device, but >> registered no input). >> >> I used Tor Browser and the Tails downloader plugin to download the Tails 3.3 >> ISO >> (the first deterministically-built one) on my development laptop (a Thinkpad >> X1 >> Carbon Gen4), and verified its GPG signature. SHA256 hash of the ISO: >> >> 5ac6b8a563a999701aa394a0761ba3e29d5a964537549e5b4a81b2abf12a1c09 >> >> I also installed tails-live-installer from their PPA. >> >> 2017-11-22 >> - ---------- >> >> I opened up the laptop again, and confirmed that the wireless functionality >> and >> speakers were still disabled. I then removed the hard drive and re-assembled >> the >> laptop. From this point onward, I did not let the laptop (henceforth >> referred to >> as the compute node), nor any of the USB drives, out of my sight for more >> than a >> few seconds. >> >> I rolled a dice to select one of the five USB drives at random. I used >> tails-live-installer to install Tails 3.3 on the USB drive. I then realised >> that >> I hadn't yet upgraded the drivers for my development laptop to fix the Intel >> AMT/ME vulnerability. I booted into the Windows partition to do so. >> Following >> this, I rebooted into Ubuntu again, imaged the USB drive, and then wiped it >> and >> re-installed Tails 3.3. >> >> I installed Docker CE on my development laptop, and used Andrew Miller's >> Dockerfile to deterministically build the powersoftau compute binary. SHA256 >> hash: >> >> 922b2e0a59841ecdaba7b4953d8c67e62b74b8f52f968624cff664dc086da93a >> >> On my Qubes 3.2 laptop (a Purism Librem 15) I created a disposable VM, and >> downloaded the challenge file in it. SHA256 hash: >> >> d27e5d6c5a7611f6690443d8a47c6ebd134bc863f05984d9b3d845060a3f036a >> >> I created a fresh AppVM for staging (backed by the fully-upgraded >> fedora-24-minimal TemplateVM) with network access. I ran the following >> commands: >> >> $ su - (the minimal template does not have sudo) >> $ dnf config-manager \ >> --add-repo \ >> https://download.docker.com/linux/fedora/docker-ce.repo >> $ dnf install docker-ce >> $ docker --version >> Docker version 17.06.0-ce, build 02c1d87 >> $ systemctl start docker >> $ docker run -it socrates1024/powersoftau >> [snip] >> Digest: >> sha256:3d42ec3bc947c410dca07e4bbbe5e88bf264b147ecaa87807ec58424f309b046 >> $ $ sha256sum target/x86_64-unknown-linux-musl/release/compute >> >> 922b2e0a59841ecdaba7b4953d8c67e62b74b8f52f968624cff664dc086da93a >> >> Having obtained the same binary hash on both machines, I then fetched the >> compute binary out of the staging AppVM's Docker container, and copied the >> challenge file from the disposable AppVM to the staging AppVM. I also >> downloaded >> EFF's long wordlist: >> https://www.eff.org/files/2016/07/18/eff_large_wordlist.txt >> SHA256 hash: >> >> addd35536511597a02fa0a9ff1e5284677b8883b83e986e43f15a3db996b903e >> >> BEGIN COMPUTATION STEPS >> ``````````````````````` >> I rolled a dice to select one of the four remaining USB drives at random. I >> attached the USB drive to my Qubes laptop, and then redirected it from >> sys-usb >> to the staging AppVM using qubes-usb on Dom0. I copied the challenge file, >> the >> compute binary, and the wordlist to the USB drive. >> >> I took the compute node, Tails USB drive, and challenge USB drive to a room >> at >> the far end of the house (from the router), which had the most line-of-sight >> granite surrounding it, and also had a large metal filing cabinet. I emptied >> one >> of the drawers and set up the compute node inside it. I inserted the Tails >> USB >> drive, started the compute node, and disabled SecureBoot. Once in the Tails >> environment, I inserted the challenge USB drive, copied the compute binary >> and >> wordlist to the Tails home directory (in RAM), and symlinked the challenge >> file >> into that directory (as I didn't have enough RAM to hold the challenge file >> in >> memory twice). >> >> I started the compute binary, opened the wordlist, and then used five dice >> (of >> assorted sizes, that I scrounged from around the house) in a cardboard box >> to >> generate an eight-word random phrase. I typed the phrase into the compute >> binary >> input (space-separated, no leading or trailing spaces), and also wrote it >> down >> on the inside of a piece of folded card. I then started the computation >> process, >> and closed the filing cabinet drawer. The computation took around 40 >> minutes, >> during which I sat beside it, occasionally pulling the drawer open slightly >> to >> check progress, and reading Serious Cryptography in between. At the point >> where >> I noticed that the challenge itself had been read into memory, I unmounted >> and >> removed the challenge USB drive. >> >> After the computation was completed, I rolled a dice to select one of the >> three >> remaining USB drives at random. I copied the response file to it, and used >> my >> phone to tweet out the BLAKE2b hash printed by the compute binary: >> >> 2c052c1f 039810e7 69779017 9943bdb9 >> d00a84fb 25593453 85af3826 1fbe061c >> 4dc79f4e 87da26f4 3202bcf4 3960db16 >> be870511 7f3de50c 8922b502 32a3e126 >> >> I then shut down the compute node. >> >> END COMPUTATION STEPS >> ````````````````````` >> >> I repeated the steps above a second time (using the two remaining USB >> drives), >> to obtain a second response file, and a second BLAKE2b hash: >> >> 3df44b57 4c66cb75 9bba2f2a 96b12ea1 >> 9037a70c 4c898397 35ad6b3d 50b84715 >> 39bfdea2 0d6e6db3 79ce6f3d 3d823d32 >> 901d2651 20481863 45d99475 e63a91a9 >> >> Finally, I rolled a dice to decide which of the two responses to upload; the >> dice landed on an odd number, meaning that I uploaded the first response. I >> am >> revealing the randomness used to compute the second response: >> >> boogeyman amber reverse oversight scorn impending wheat engraver >> >> After typing in the above phrase, I burned the card on which I had written >> the >> two random phrases. I opened up the compute node, and removed the battery >> and >> RAM stick. I have not yet destroyed the RAM chips, and am keeping the stick >> on >> my person until I am able to (so I've probably damaged it already with >> static). >> >> I connected the USB drive containing the first response to my Qubes laptop, >> and >> then redirected it from sys-usb to the staging AppVM. I then copied the >> response >> to the disposable AppVM, and then into another AppVM to upload it to one of >> my >> personal servers (as the upload to AWS was timing out). >> >> >> Security Considerations >> ======================= >> >> - - The laptop was chosen randomly, with as little unreported bias as >> possible, >> and with my participation at that point only mentioned to Sean. However, a >> sufficiently-motivated adversary could potentially have figured out that I >> was >> participating, guessed which store I would go to on my route, and >> persuaded >> the staff to alter the displays to draw my attention towards a particular >> laptop. A constraint, or a private deterministic metric for selection, may >> have helped to eliminate more bias. >> >> - - Using a deterministically-built ISO for the operating system should make >> it >> easier to determine the OS code that was running at the time, modulo the >> trust >> in the machine that the live USB was built on (which is my Zcash dev >> laptop). >> >> - - Using a fresh Qubes AppVM for staging increases the bar for having >> compromised >> the OS in order to compromise the challenge USB drive. >> >> - - Tails by default disables sudo and mounts itself as read-only, meaning >> that a >> malicious userspace process shouldn't be able to persist data on that USB >> drive. >> >> - - Tails by default mounts plugged-in USB drives as read-write. Using a >> fresh USB >> drive each time to transfer the compute binary, challenge and wordlist to >> the >> compute node removed that as a vector for persistance between iterations. >> >> - - Revealing the randomness in the unused response, after the compute node >> had >> been shut down, should make it possible to ascertain that the compute >> binary >> was behaving correctly, by having third parties independently re-compute >> the >> corresponding response file and verify the hash against the one I >> published. >> >> >> Things I'd Do Differently In Future >> =================================== >> >> - - Pick somewhere with faster internet. The internet here isn't snappy to >> begin >> with, and it was raining and blowing which significantly impacts speeds. >> As a >> result, the challenge file took several hours to download, and the >> response >> file took probably double that. >> >> - - Use a DVD to set up the compute OS instead of a USB (and then load the >> OS into >> RAM to free up the DVD drive). A DVD would in theory be more easily >> auditable, >> putting less trust in the machine creating it than the live USB. This >> would >> also increase the amount of RAM required in the machine (I ran this >> entirely >> in 4GB memory). >> >> - - Build the compute binary ahead of time. In particular, the time it took >> to >> download Docker and build dependencies (twice) significantly extended the >> setup time. >> >> - - The binary was built deterministically, but it would be preferable to >> have it >> only use dependencies and a compiler that could be reasonably assumed to >> not >> have backdoors targeted at the MPC in general or participants in >> particular. I >> did briefly try to compile Devrandom's branch, but decided determinism was >> more important for now. >> >> - - Monitor and keyboard. I had to open the filing cabinet drawer in order >> to type >> in the randomness and monitor progress; an external monitor and keyboard >> would >> limit the EM leakage of doing so. >> >> - - Hardware separation of randomness. There was maybe 10 minutes between >> compute iterations (as I created the second challenge USB drive), and the >> battery was not removed in between (as that required disassembly), so >> there is >> a small but non-zero possibility that the second computation could have >> been >> influenced by (maliciously or otherwise) the first one. In this case it >> happens to not matter much, as the random roll at the end selected the >> result >> of the first computation, but in a future MPC I'd prefer to at least >> remove >> the battery in between runs, and ideally swap out the RAM. >> >> - - Different response extraction mechanism. I neglected to purchase a DVD >> reader >> for my existing laptops, so could not use DVDs as the airgap mechanism, >> falling back to the USB drives. I also had a more ambitious mechanism in >> mind, >> but that will require significant additional development work. >> >> - - Use a separate AppVM for staging the response. I had intended to do this >> (to >> limit the ability of any malicious data hidden on the response USB to >> escape), >> but reused the previous qubes-usb command neglecting to change the AppVM >> name. >> Once it was connected to the challenge staging VM, I decided that any >> damage >> had already been done, and continued. >> >> -----BEGIN PGP SIGNATURE----- >> >> iQIcBAEBCgAGBQJaFib5AAoJEGZdvNKE99r/tHsP/jZjS+VbrYQz0pHi9MS4wQzP >> 4kErUDJgF8t6TkNj6W4ZCBIu9ryEQthUxpMgDEqbRFt9M7ueYB8bys9YUtna7fVJ >> tyrj7UmPlYGOLs6QaFaE+TBhnDoWA+bdHNb5bHzC2mWaXwya3DYrW5ai7BA7/YUF >> hcW5dMtyQRrL4vKMLWq500nhZ1n5aa0Njq0NJ3XEzDa3W4+Wq3nJBTk5NNXz0iAC >> +h0j542AlrHcp4dzWf/PvBpZrnerpMlMatJmR/GN0153tbdFVs8zqPAfRmLvyl3m >> vYPuW4S/QGUoKKsyM3zJps3QtaNQJooHkD8Y6nOBbX9piEURy2hZUMoPYhiIVyM7 >> T8wvt3UNXjBAzzoNWOSt8+s/OMGt+E++9bFKxOKqE2zXQAxIGGVxYfc563DHM051 >> BuYNSfYKwoFP5Cq2pU2j6WOGs20zQxh6ySRd8Iz1v5uJSQ0Z6+GJ9Ddc1Lo2YDpt >> hcPa8oe2vGReuX33lN6PBNYjr+CkwV8metJXG+2irKCTGdgaBv+IweBUkP4SUxe6 >> C0kmxjgQ9BJ0/kW4EHeyIS1YGFAyZDbXedsaSRBvBNegnCYfCavPKBIYcRINrCPk >> 1XJ/J6Lhhc0xC4fILsXhot3uoAl1QHwT69a5Gfj/nTCSaJ6E3vbbaOgr8Igu6Jf8 >> VCTWs0YxUiG8EctFHElQ >> =uVQb >> -----END PGP SIGNATURE-----
