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.


On Wed, Nov 22, 2017 at 6:49 PM, Jack Grigg via zapps-wg
<> wrote:
> 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
> (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 \
> $ 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:
> SHA256 hash:
>     addd35536511597a02fa0a9ff1e5284677b8883b83e986e43f15a3db996b903e
> ```````````````````````
> 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
> 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.
> `````````````````````
> 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.
> 4kErUDJgF8t6TkNj6W4ZCBIu9ryEQthUxpMgDEqbRFt9M7ueYB8bys9YUtna7fVJ
> tyrj7UmPlYGOLs6QaFaE+TBhnDoWA+bdHNb5bHzC2mWaXwya3DYrW5ai7BA7/YUF
> hcW5dMtyQRrL4vKMLWq500nhZ1n5aa0Njq0NJ3XEzDa3W4+Wq3nJBTk5NNXz0iAC
> +h0j542AlrHcp4dzWf/PvBpZrnerpMlMatJmR/GN0153tbdFVs8zqPAfRmLvyl3m
> vYPuW4S/QGUoKKsyM3zJps3QtaNQJooHkD8Y6nOBbX9piEURy2hZUMoPYhiIVyM7
> T8wvt3UNXjBAzzoNWOSt8+s/OMGt+E++9bFKxOKqE2zXQAxIGGVxYfc563DHM051
> BuYNSfYKwoFP5Cq2pU2j6WOGs20zQxh6ySRd8Iz1v5uJSQ0Z6+GJ9Ddc1Lo2YDpt
> hcPa8oe2vGReuX33lN6PBNYjr+CkwV8metJXG+2irKCTGdgaBv+IweBUkP4SUxe6
> 1XJ/J6Lhhc0xC4fILsXhot3uoAl1QHwT69a5Gfj/nTCSaJ6E3vbbaOgr8Igu6Jf8
> =uVQb

Reply via email to