Re: [zapps-wg] Powers of Tau Ceremony Proposal

[Eric L. Stromberg via zapps-wg]

-BEGIN PGP SIGNED MESSAGE-Hash: SHA512Powers of Tau Operational writeup=Round: 7Date: 2017-11-16Name: Eric L. StrombergLocation: San Francisco area, USChallenge: 2ae068fbe1a9d0e070844047f3032432e86b822f593da3fcd6fc0ee8bed2f30caac587a1d5e68ea6fcdcf1a40213de7d41ded05cf9be934e4c6d617e201caa1aResponse: 1ad851c65b4fcf3ca0bce6b366c40c48b65f611044731faf2b5fc90f987eda3f3240ea25c555e516ff73de2855369fd2da77a7055529b6f72ac3225b07fd8585 Preparation steps=UBUNTUBuild VM & compute node OS from: ubuntu-16.04.3-desktop-amd64.isoSHA256: 1384ac8f2c2a6479ba2a9cbe90a585618834560c477a699a4a7ebe7b5345ddc1  Build VM, create compute binary:Created new Ubuntu 16.04.3 VM from ISOFollowed instructions indicated in repository Readme to build “compute” binaryhttps://github.com/ebfull/powersoftau [commit 9e1553c437183540392a7231d0788318a19b18a3]Formatted fresh 8GB USB stick, copied compute binary to it.BLAKE2b-64 (./compute) = 7af5d31bbb215eab40753043523790483cdda67aef1d6e317f4269fb042dbc8608feaa0db8d17df82bef28f021509871635a56052de1370f4b90dc6322a8a962Setup 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.zipSHA256: 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 OSXBuild 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) = 88565a9e84c9ee69818e78909b7f6b05ef46a88780b8378d44a037be7e8fd50c7c601e8340455be2ed9e703095baf3f9104fded0086576c9c43c36fb6bf9Installed 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=0Procedure=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 defensesThe 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 - 

Re: [zapps-wg] Eliminating the possibility of backdoors with high probability

[Peter Todd via zapps-wg]

On Mon, Nov 13, 2017 at 08:26:04PM -0700, Sean Bowe wrote:
> > Q: What exactly happens if one participant fails to destroy that secret 
> > and/or
> > inputs a low-entropy secret? What about N participants?
> >
> > The paper states that "We show that security holds even if an adversary has
> > limited influence on the beacon." but it's unclear what exactly "limited
> > influence" means.
> 
> My understanding was that we lose N bits of security when an attacker
> can influence N bits of the randomness beacon.

Oh, I might have misunderstood the paper then: when it says "Random beacon" it
really does mean an external random beacon such as the NIST Randomness Beacon,
not something generated within the ceremony itself?

> This MPC is of the "only one has to be honest" kind. It is irrelevant
> if N-1 of the participants have low entropy / known secrets, so long
> as just one has high entropy w.r.t. the security parameter.

Right

> > As N increases you open up a new exfiltration route: the unused N-1 
> > responses
> > could themselves be the exfiltration route, and thus need to be
> > deterministically verified against the N-1 unused secrets. This isn't
> > particularly user-friendly, and it's easy to imagine how this could be 
> > skipped.
> 
> Note that the compute process prints out a hash of the response file,
> and so we can "cut-and-choose" in the same way to guard against these
> exfiltration routes. As an example, if we use DVDs, we can burn N
> response files and note each's respective hash and entropy. Then,
> reveal N-1's hash/entropy, but destroy those N-1 DVDs.

But note here how there's more opportunities to leak data because the
secrets(1) associated with each DVD are simultaneously available to the
attacker. OTOH, by simply doing each round separately the code is both simpler,
and the attacker has access to less information as only one secret should be
available to them at a time.

1) Entropy is an *implementation* of a secret; entropy itself isn't enough.

> > Finally, it's interesting how there's a whole class of "sham" participant
> >strategies, where someone who runs the computation and uploads an audit
> >response w/ revealed secret, but does not actually participate in that round,
> >still frustrates attackers who can not tell in advance if that particular
> >participant will or will not actually participate. This suggests that the
> >current round's challenge should be made public.
> 
> That's very interesting. Right now the transcript is public and so the
> current challenge can be computed by anyone, but it would be a little
> better if I put the "current" challenge file up for download.

Publishing a link on this mailing list would work well. Secondly, as we'll have
to archive all this stuff anyway, I'd suggest using the Internet Archive for
distribution of the challenges.

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org


signature.asc
Description: Digital signature

Re: [zapps-wg] Version of Rust

[Sean Bowe via zapps-wg]

I think it is the current version (1.21). I imagine it would be
possible to modify the code (and many of the dependencies) so that it
could compile on a really old version too.

Sean

On Thu, Nov 16, 2017 at 1:35 PM, Devrandom via zapps-wg
 wrote:
> Hi Sean,
>
> Do you know what is the oldest version of Rust that will successfully
> compile the Tau software?
>

[zapps-wg] Version of Rust

[Devrandom via zapps-wg]

Hi Sean,

Do you know what is the oldest version of Rust that will successfully
compile the Tau software?