Re: [zapps-wg] Powers of Tau Attestation

[Devrandom via zapps-wg]

I'm attaching an OpenTimestamps receipt for my attestation.

On Tue, Mar 13, 2018 at 11:51 AM Devrandom 
wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> # Powers of Tau Attestation
>
> Author: devrandom
> Date: 12 March 2018
>
> Notes:
>
> * Hardware is an Intel laptop that has not been powered up in four years
> and has never been connected to a network after it was purchased.  CPU was
> a Celeron 1007U.  Wireless card was removed.
> * OS was a clean Ubuntu 14.04
> * Compute binary was created with a deterministic Gitian build, with
> report here:
> https://github.com/devrandom/golang-powersoftau/commit/241da6dac6166a68ff20ef7abbb0f8231a626a3c.
> The binary sha256sum is
> c28894877c8948960eaefa0d8f35da6c911031980672b983f361711a7dcb1ec8.  The
> binary was archived for future research.
> * A USB drive was purchased in person and used to transfer the binary and
> challenge into the laptop and the response out of the laptop.
> * Additional entropy was injected into /dev/random via keyboard mashing
> and dice throws
> * The laptop was disconnected from AC throughout the computation
> * The boot drive was destroyed
>
> The BLAKE2b hash is:
>
> a449bc6e d77cbc7b 2d6aa91b ac4ddc6e
> e398a6e8 6c2b08dd 529b796b f7fcfb7c
> ba5cfb94 a394731d e1a188ec bdf6dcaf
> 8444f688 975973ca 079b94f2 e0e7def0
>
> -BEGIN PGP SIGNATURE-
>
> iQEcBAEBCAAGBQJaqB0pAAoJEOOqsosn9c9K66MH/j79TuEGpSdS5weTRxKHVMHJ
> NMLEGdnFT6BVEIJrIbzC1eQFJHWQhROokTn0mrjaV3lsGSWXJ5D91/rYE6boVsrN
> o501eDQui1nSnkIICrQY3aDnzYIT98crtGPDBD29e8vTRqjGnWAay1ovjIA5Vr0V
> q3nxfrp2mqdk9kYFHDfLvjfeEJRkOujx1TrwRRqX2/0OTLnAnPgrqUncKaiojH0v
> IlcbYAoBe2VEboiwN1QDMV0AuYzNCfrTXsof0lU6g7sZwy49MLCQNsUmxW2bl3jz
> AzlCjcBG6EyLyh5T6J+FylEYrplcPdlZLmtcGNsdoM1VeohpL3f7ZqALUlCJjQU=
> =IvmM
> -END PGP SIGNATURE-
>
>


attestation.md.asc.ots
Description: application/vnd.oasis.opendocument.spreadsheet-template

[zapps-wg] Powers of Tau Attestation

[Devrandom via zapps-wg]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

# Powers of Tau Attestation

Author: devrandom
Date: 12 March 2018

Notes:

* Hardware is an Intel laptop that has not been powered up in four years
and has never been connected to a network after it was purchased.  CPU was
a Celeron 1007U.  Wireless card was removed.
* OS was a clean Ubuntu 14.04
* Compute binary was created with a deterministic Gitian build, with report
here:
https://github.com/devrandom/golang-powersoftau/commit/241da6dac6166a68ff20ef7abbb0f8231a626a3c.
The binary sha256sum is
c28894877c8948960eaefa0d8f35da6c911031980672b983f361711a7dcb1ec8.  The
binary was archived for future research.
* A USB drive was purchased in person and used to transfer the binary and
challenge into the laptop and the response out of the laptop.
* Additional entropy was injected into /dev/random via keyboard mashing and
dice throws
* The laptop was disconnected from AC throughout the computation
* The boot drive was destroyed

The BLAKE2b hash is:

a449bc6e d77cbc7b 2d6aa91b ac4ddc6e
e398a6e8 6c2b08dd 529b796b f7fcfb7c
ba5cfb94 a394731d e1a188ec bdf6dcaf
8444f688 975973ca 079b94f2 e0e7def0

-BEGIN PGP SIGNATURE-

iQEcBAEBCAAGBQJaqB0pAAoJEOOqsosn9c9K66MH/j79TuEGpSdS5weTRxKHVMHJ
NMLEGdnFT6BVEIJrIbzC1eQFJHWQhROokTn0mrjaV3lsGSWXJ5D91/rYE6boVsrN
o501eDQui1nSnkIICrQY3aDnzYIT98crtGPDBD29e8vTRqjGnWAay1ovjIA5Vr0V
q3nxfrp2mqdk9kYFHDfLvjfeEJRkOujx1TrwRRqX2/0OTLnAnPgrqUncKaiojH0v
IlcbYAoBe2VEboiwN1QDMV0AuYzNCfrTXsof0lU6g7sZwy49MLCQNsUmxW2bl3jz
AzlCjcBG6EyLyh5T6J+FylEYrplcPdlZLmtcGNsdoM1VeohpL3f7ZqALUlCJjQU=
=IvmM
-END PGP SIGNATURE-

Re: [zapps-wg] Cut-off date for Powers of Tau Contributions

[Devrandom via zapps-wg]

That's a good idea.  Also, please let me know if I can have my turn on
Sunday.

On Fri, Mar 9, 2018 at 12:06 PM Andrew Miller  wrote:

> What if we just reach out to everyone currently in queue and ask them to
> use the golang version (and save the binaries)
>
> On Fri, Mar 9, 2018 at 2:57 PM, Devrandom 
> wrote:
>
>> I can take care of the first bullet point (hopefully on ARM64), but would
>> be nice if we had more than one additional round with golang.
>>
> On Fri, Mar 9, 2018 at 11:22 AM Andrew Miller 
>> wrote:
>>
> It sounds like an efficient way to dispense with the suggestions Devrandom
>>> raised are to:
>>> 1. Do a round with the deterministic Go build, explicitly saving the
>>> binary for posthoc analysis, and ideally running it on a non x86
>>> architecture if anyone has one...
>>> 2. Do a round with mrustc
>>> What would it take to get a concrete plan to include those?
>>>
>>> On Fri, Mar 9, 2018 at 2:17 PM, Sean Bowe  wrote:
>>>
 As far as security goes, we've successfully guarded against all but
 the most elaborate and unrealistic attack scenarios. The remaining
 threats require some combinatorial explosion of individually
 sophisticated attacks or breakthroughs, like stealthy backdoors in the
 Rust compiler and still for many participants to be colluding in
 secret, somehow without leaving evidence behind.

 We don't need an absolutely perfect ceremony to get strong privacy
 guarantees, we get that already even with a totally compromised
 ceremony. We *could* continue to invest time and resources for many
 more months or years in order to make us marginally more resistant to
 these absurd attack scenarios, but by the time we'd be finished with
 the ceremony we'll probably have better proving systems available
 anyway. It's silly to let privacy languish in the meantime.

 I think we did the best with the time we had, but if you disagree,
 remember that all of this can be extended and improved by anyone, even
 after this ceremony is done!

 Sean

>>>
 On Fri, Mar 9, 2018 at 11:06 AM, Peter Todd  wrote:

>>> > On Fri, Mar 09, 2018 at 04:49:37PM +, Devrandom wrote:
 >> Hi all,
 >>
 >> I have some concerns about the lack of diversity of contributions:
 >>
 >> - most (all?) of the contributions used a distributed Rust
 toolchain, which
 >> suffers from the "trusting-trust" issue since they are
 self-compiled.  I
 >> don't think I've seen any contributions using the mrustc build path.
 >> - there were very few contributions (two?) using the golang
 implementation
 >> - no attempt has been made to replicate the deterministic golang
 build
 >> - people did not capture the binary they used, so we can't do
 forensics in
 >> case of future questions
 >> - there were no contributions using alternative processor
 architectures
 >> (e.g. ARM64).  I believe this is possible using the golang
 implementation.
 >> - there was a lot of focus on destroying toxic waste and not enough
 on the
 >> trustworthiness of the tools
 >
 > I agree with all these points, particularly the latter: we should be
 focused on
 > genuine security, not flashy marketing stunts. (indeed, I regret the
 way my own
 > participation was marketted the last time around)
 >
 > --
 > https://petertodd.org 'peter'[:-1]@petertodd.org

>>>
>>> --
>>> Andrew Miller
>>> University of Illinois at Urbana-Champaign
>>>
>>
>
>
> --
> Andrew Miller
> University of Illinois at Urbana-Champaign
>

Re: [zapps-wg] Cut-off date for Powers of Tau Contributions

[Devrandom via zapps-wg]

Hi all,

I have some concerns about the lack of diversity of contributions:

- most (all?) of the contributions used a distributed Rust toolchain, which
suffers from the "trusting-trust" issue since they are self-compiled.  I
don't think I've seen any contributions using the mrustc build path.
- there were very few contributions (two?) using the golang implementation
- no attempt has been made to replicate the deterministic golang build
- people did not capture the binary they used, so we can't do forensics in
case of future questions
- there were no contributions using alternative processor architectures
(e.g. ARM64).  I believe this is possible using the golang implementation.
- there was a lot of focus on destroying toxic waste and not enough on the
trustworthiness of the tools

Lastly, the deadline was announce less than a week in advance, which makes
it difficult to address the above issues.

On Thu, Mar 8, 2018 at 5:25 PM Andrew Miller via zapps-wg
 wrote:

> Let me add a bit to this:
> 1. First of all, all the code you need to add your own rounds to
> powers-of-tau is already provided in Sean's repo. You could fork the
> repository and add more rounds yourself if you wanted to. You could also
> start using the powers-of-tau from early phases if you want too.
> 2. While we'll go along with Sean's suggestion to conclude the "official"
> one on Mar 15, which will be used for Sapling, if there's interest from the
> community in continuing to add more rounds, the Foundation will continue to
> facilitate that, probably in another branch to avoid any confusion.
> 3. So far we have only been doing powers of tau for the 2^21 size circuit,
> over the BLS12-381 curve. If there is any interest in conducting Powers of
> Tau for larger circuit sizes, or for different curves (such as the
> alt_bn128 supported in Ethereum), then the Foundation would support that
> too. Although someone would have to adapt Sean's or FiloSottile's code to
> do so...
>
> Cheers,
>
> On Mon, Mar 5, 2018 at 11:03 PM, Sean Bowe via zapps-wg <
> zapps...@lists.z.cash.foundation> wrote:
>
>> We're almost finished with the Powers of Tau ceremony!
>>
>> On March 15 no new contributions will be accepted. If you still want to
>> participate, you will need to contact Jason Davies ASAP and arrange for a
>> time.
>>
>> I'll be making an announcement about the random beacon soon.
>>
>> Thanks,
>>
>> Sean
>>
>
>
>
> --
> Andrew Miller
> University of Illinois at Urbana-Champaign
>

[zapps-wg] Submitted trusting-trust issue against Rust

[Devrandom via zapps-wg]

As a reminder - the issue is that we can't prove that the Rust compiler is
malware free, because it is compiled with itself.

The submitted issue is here: https://github.com/rust-lang/rust/issues/48707

[zapps-wg] Powersoftau deterministic build

[Devrandom via zapps-wg]

I have submitted a pull request for doing a deterministic build of the
Golang powersoftau implementation.  The pull request is here:
https://github.com/FiloSottile/powersoftau/pull/4 . The guest OS is Debian
9 (stretch), due to the requirement for Golang 1.7+.

This was tested as follows:

- Ubuntu 17.10 host with Virtualbox
- Ubuntu 16.04 host with LXC

Other combinations may work, but KVM is known to not work with a Debian
guest.

Until this is merged, you can follow the README but clone my branch instead:

git clone git@github.devrandom/golang-powersoftau

Please try to replicate my resulting SHA256 hash:

c28894877c8948960eaefa0d8f35da6c911031980672b983f361711a7dcb1ec8  taucompute

Re: [zapps-wg] The Go implementation of Powers of Tau

[Devrandom via zapps-wg]

Very happy to hear about the go implementation for a couple of reasons:

- this gives us another path to trusted binaries from pure source + gcc
- this may work well on ARM64, which gives us another architecture - one
that doesn't have a management engine (in contrast, mrustc currently only
works on x86)

It would be good to look into how distributions compile their go binaries -
whether they use the latest version of the toolchain, or they bootstrap
from golang 1.4 (which only depends on gcc).  If they use the latest, it
would be good to have people compile their own from source.

About the mrustc work that I've done - I don't think the lack of
determinism is a showstopper.  It just means that contributors have to
compile from source, which is time consuming.  Perhaps there was some
miscommunication about that?


On Sun, Jan 28, 2018 at 5:12 AM Sean Bowe via zapps-wg
 wrote:

> Great work on this. I wonder if this implementation will be a better
> foundation for fully-deterministic and trustworthy builds? I am
> disappointed that devrandom's efforts were stymied by non-determinism
> in the Rust compiler. :(
>
> Sean
>
> On Sat, Jan 27, 2018 at 12:30 PM, Filippo Valsorda via zapps-wg
>  wrote:
> > Hello folks,
> >
> > https://github.com/FiloSottile/powersoftau is a fully independent
> implementation of Powers of Tau. It is written in Go, shares no code with
> the main Rust implementation, and uses the RELIC library for BLS12-381.
> >
> > I used it for my contribution, but for it to be truly valuable to the
> security of the MPC ceremony more people need to run it, including in more
> secure settings than my laptop.
> >
> > The README includes build instructions. If there are any problems feel
> free to open an issue on GitHub or email me.
> >
> > To enable people to run both implementations there's a -next option to
> generate the next challenge file while computing the response. This is much
> faster than running verify_transform as it doesn't do verification and it
> doesn't have to decompress points.
> >
> > You should assume that secret material will be left in memory, and
> protect against side channels, just like with the Rust implementation.
> >
> > _o/
>

Re: [zapps-wg] Trusted Rust build process is ready for evaluation

[Devrandom via zapps-wg]

Verification passed (in fact, new_challenge was identical).

BTW, would be nice if `compute` had a flag to only take entropy from STDIN,
so that we can check for any differences in the response.

On Tue, Dec 5, 2017 at 12:48 PM Devrandom  wrote:

> Thank you.  Will do the verification shortly.
>
> Also, I've updated the instructions in
> https://github.com/devrandom/powersoftau/wiki/Trusted-build-instructions-via-mrustc
>  to
> use the cargo built by mrustc.  This required vendoring of the dependencies.
>
>
> On Tue, Dec 5, 2017 at 11:24 AM Sean Bowe  wrote:
>
>> Excellent work! :)
>>
>> new, compute, verify_transform is a good demonstration. I would
>> verify_transform with a binary compiled with the normal Rust compiler
>> to double-check.
>>
>> Sean
>>
>> On Tue, Dec 5, 2017 at 11:59 AM, Devrandom 
>> wrote:
>> > Hi all,
>> >
>> > I was able to build rustc completely from sources.  This means no
>> network
>> > access during the build and without any Rust distributed binaries.
>> >
>> > The steps are here:
>> >
>> >
>> https://github.com/devrandom/powersoftau/wiki/Trusted-build-instructions-via-mrustc
>> >
>> > I'm still looking into building a cargo binary that supports TLS, to
>> > eliminate the need to download it for building powersoftau itself.
>> Worst
>> > case we can use a shell script.
>> >
>> > Would like to merge https://github.com/ebfull/pairing/pull/72 so that
>> we
>> > don't have to maintain a separate patch for Rust 1.19 compatibility.
>> >
>> > Sean, what is the best method of validating that the generated binary
>> works
>> > correctly?  Just use "new", then "compute" and then "verify_transform"?
>> >
>> > Also, I found that the generated binary is *very* different from the one
>> > generated by the downloadable Rust compiler.  This is somewhat
>> worrisome,
>> > although it doesn't affect us if we use the mrustc path.  Will spend a
>> bit
>> > more time to get to the bottom of it.
>> >
>>
>

Re: [zapps-wg] Trusted Rust build process is ready for evaluation

[Devrandom via zapps-wg]

Thank you.  Will do the verification shortly.

Also, I've updated the instructions in
https://github.com/devrandom/powersoftau/wiki/Trusted-build-instructions-via-mrustc
to
use the cargo built by mrustc.  This required vendoring of the dependencies.


On Tue, Dec 5, 2017 at 11:24 AM Sean Bowe  wrote:

> Excellent work! :)
>
> new, compute, verify_transform is a good demonstration. I would
> verify_transform with a binary compiled with the normal Rust compiler
> to double-check.
>
> Sean
>
> On Tue, Dec 5, 2017 at 11:59 AM, Devrandom 
> wrote:
> > Hi all,
> >
> > I was able to build rustc completely from sources.  This means no network
> > access during the build and without any Rust distributed binaries.
> >
> > The steps are here:
> >
> >
> https://github.com/devrandom/powersoftau/wiki/Trusted-build-instructions-via-mrustc
> >
> > I'm still looking into building a cargo binary that supports TLS, to
> > eliminate the need to download it for building powersoftau itself.  Worst
> > case we can use a shell script.
> >
> > Would like to merge https://github.com/ebfull/pairing/pull/72 so that we
> > don't have to maintain a separate patch for Rust 1.19 compatibility.
> >
> > Sean, what is the best method of validating that the generated binary
> works
> > correctly?  Just use "new", then "compute" and then "verify_transform"?
> >
> > Also, I found that the generated binary is *very* different from the one
> > generated by the downloadable Rust compiler.  This is somewhat worrisome,
> > although it doesn't affect us if we use the mrustc path.  Will spend a
> bit
> > more time to get to the bottom of it.
> >
>

[zapps-wg] Trusted Rust build process is ready for evaluation

[Devrandom via zapps-wg]

Hi all,

I was able to build rustc completely from sources.  This means no network
access during the build and without any Rust distributed binaries.

The steps are here:

https://github.com/devrandom/powersoftau/wiki/Trusted-build-instructions-via-mrustc

I'm still looking into building a cargo binary that supports TLS, to
eliminate the need to download it for building powersoftau itself.  Worst
case we can use a shell script.

Would like to merge https://github.com/ebfull/pairing/pull/72 so that we
don't have to maintain a separate patch for Rust 1.19 compatibility.

Sean, what is the best method of validating that the generated binary works
correctly?  Just use "new", then "compute" and then "verify_transform"?

Also, I found that the generated binary is *very* different from the one
generated by the downloadable Rust compiler.  This is somewhat worrisome,
although it doesn't affect us if we use the mrustc path.  Will spend a bit
more time to get to the bottom of it.

Re: [zapps-wg] Request to join MPC ceremony

[Devrandom via zapps-wg]

Curious if you saved your compute binary?

On Mon, Nov 27, 2017 at 9:32 PM Neal Conner via zapps-wg
 wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Powers of Tau Operational Write-up
> ==
>
> Round: 18
> Date: 2017-11-25
> Name: Neal Jayu
> Location: Boston, Massachusetts, New England
>
> Hashes
> ==
>
> challenge:
> c2d62e5fdff19023554f21d19b86490470ac9a2860094d10397c666f9c6fc652
>
> response (blake2b & sha256):
> ef15cb99 7c331928 855dd7ce 42ade214
> 3033be18 5be45f3e eac5b95b b12777db
> 582992b0 a862c92a 1cba4e95 044c52f5
> de857776 31462a0d c51d7a4f 846b9d7e
> 122efac62a11da143dca24e5facd33cf61ff2597e65aa4ff09aae89fe838c045
>
> powersoftau-master.zip:
>
> 3a6db71b0bb9d39c3f58f2d51388560ab92b139d5066eb9b66c30580262309d7147289fb598926a5d99779935b30411b075504b2ebd0488335c6e9df5bf80e00
>
> rust-1.22.1-x86_64-unknown-linux-gnu.tar.gz:
>
> 0fd3776a7fd38cbcbffe8a257836f9f5c0d04762af3107b93b8860b98b6d92b0912b4668c973d9f647a7a74b4855a5680cab042c3389c6158efee1b4640a60de
>
> debian-9.2.1-amd64-DVD-1.iso:
>
> b7afe686f36f9e26ac0888ca341572d2bf1fbe70c50acb6af822cf9e04318e5a3f974ebdfd91e1706758f0f2aa1a332462f3d74ecdaf69f0061849ac595e67df
>
> Procedure
> =
>
> After downloading the aforementioned files to my daily Linux machine, I
> checked each's sha256/512 sum against published values, or in the case
> of the Rust standalone, recorded its sha512 sum and verified its
> signature file against the project's PGP key from Keybase.
>
> I burnt the Powers of Tau zip, Rust standalone installer, Debian ISO,
> and Memtest86+ to DVD/CDs; and copied the challenge file to a SanDisk
> USB drive.
>
> On the compute node (see Side Channel Defences below), I booted from the
> Debian DVD, installed it to a Samsung USB drive, then booted the machine
> from the USB drive.
>
> Rust and Powers of Tau were copied from CD. Both sums were re-checked on
> the compute node. build-essential was installed from the Debian DVD.
>
> I connected Ethernet to run `cargo run --release --bin new` in order to
> download and configure dependencies. Ethernet was removed once complete,
> and the resulting challenge file deleted.
>
> The provided challenge file was copied over and computation began. As
> input, I used the results of two minutes of 20-sided dice rolls,
> followed by arbitrarily selected words from a book extolling the virtues
> of laissez-faire capitalism.
>
> One complete, a hash of the response file was taken, copied to the
> SanDisk USB drive, then uploaded to the AWS bucket via my daily machine.
>
> Side Channel Defences & Postprocessing
> ==
>
> The compute node was a disused 7-year-old Lenovo Thinkpad T420 borrowed
> from a friend without foreknowledge of my intentions for it.
>
> I removed the hard drive prior to booting the laptop. Although I did not
> have permission to remove its radio devices, I activated its hardware
> switch which purportedly disabled them.
>
> Further, during the installation of the Debian instance onto the Samsung
> USB drive, I declined to install drivers for the machine's wireless
> devices.
>
> The computation was performed within living quarters with no particular
> precautions taken save for watching Voyager at formidable volume and
> inaudibly typing the entropy sources.
>
> After copying the response file and Blake hash to the SanDisk USB drive,
> I powered off the laptop and booted into the Memtest86+ CD. I allowed
> Memtest to run for two full cycles (about 1.5 hours) then powered off.
>
> I removed power and battery from the machine and intend to leave it
> powered off for the foreseable future.
>
> Archival
> 
>
> The Debian installation media, Powers of Tau repo, Rust toolchain, and
> Memtest are on DVD/CDs which I've autographed.
>
> The Samsung USB drive containing the Debian instance, and SanDisk USB
> drive with challenge and response files (and their hashes), are both
> LUKS-encrypted. As such, I don't expect these to be tampered with
> following the operation.
>
> I've sealed all five of the above media in a signed and sealed envelope,
> which I've locked in a safe to which I alone posses the keys. They are
> available to audit upon request.
> -BEGIN PGP SIGNATURE-
>
> iQIxBAEBCAAbBQJaHPG6FBxuZWFsamF5dUBrZXliYXNlLmlvAAoJEEakC/1Nia+r
> iBwP/RQi1HIiuDoGKq5Dqv8fNr/eGUztUM/x4le3bgennM0vAomIgRuqoEZz1ng0
> JYG+jelUVzx3mSbnSnq68J3t2Nn/BEYyPGUacw1+Vp0pfJOPLQSDIwk9fXQ6tiqJ
> 862XXvSHdUzmcvw1+bRXqkDm+uHuMWja6DNfznle7u+1WAPU51Cef6efh5xpA0Mk
> wBUx9eOkxNvTrUZuyfdclfn2ZoMAlPwN+Xtw1aS4LtT6bsxR4Vpm+GFk/l5gQHyX
> 8E4mcHfRp5V2Lis3bOTdUegbp7ZjRHjL/VaZeRjW3nqslzFk6cP2gp3rzylJNyID
> guKt8hhGE92t/RXmAdkyn41mmHuao9dVus8ocdAtzRG49wqDQXcfBlj+3hUuGtJP
> v2cj7qlW4JXdGWQZTBLOTfegGIt+juBWBgszGqmrVeVFQ6A0EBDliND7hl4nk5R/
> FMCGr1CBcZmLiNvgKbKf1H4w5dyGWwBszrnZJSuIGUZLcaPDKO8xouvB4Nk3exGC
> 2d/bYYpEq/P4DBiKfKnVPacxfeJTRWg32aZF4Z0D05UNW/SJ/sdUDvzyZ0LU/kdR
> 

[zapps-wg] Rust built from source - rough draft

[Devrandom via zapps-wg]

Hi all,

I was able to build the Rust compiler almost purely from source via the
mrustc compiler.  The necessary scripts and instructions are here:

https://github.com/devrandom/trust-rust

There is still some work to be done to remove the dependency on the Cargo
binary and to vendor the sources that it currently downloads.

The diffoscope report, comparing against the distributed Linux binaries, is
here:  https://github.com/devrandom/trust-rust/wiki/initial-report .  It
would be cool to prove that the distributed binaries don't have
trusting-trust malware, but the diff is currently a bit large so not there
yet.  However, just building from source should be enough for our purposes,
since it would let us audit the sources after the fact.

I would appreciate a review of the methodology / code.

Re: [zapps-wg] Version of Rust

[Devrandom via zapps-wg]

On Mon, Nov 20, 2017 at 9:30 PM Peter Todd  wrote:

> On Mon, Nov 20, 2017 at 10:11:00PM +, Devrandom wrote:
> > Update on boostrapping via mrustc - I'm waiting on the author to resolve
> > https://github.com/thepowersgang/mrustc/issues/33.
>
> FWIW, I'm pretty sure you don't actually need cargo to compile the rust
> compiler; have you gotten mrustc to compile Rust itself?
>

The actual failure is in the rustc that was built by mrustc - see last line
of pasted blob.  Cargo is just used for convenience to trigger the build
steps (and will be replaced by a script once this issue fixed).

Re: [zapps-wg] Version of Rust

[Devrandom via zapps-wg]

On Mon, Nov 20, 2017 at 9:27 PM Peter Todd  wrote:

> On Sat, Nov 18, 2017 at 01:46:10AM +, Devrandom wrote:
> > I made some progress with walking back the Rust version, getting to
> > 2016-04-01 nightly (pre-1.8.0).  A rough cut of what I did is here:
> >
> >
> https://github.com/devrandom/powersoftau/compare/experiment-devrandom-vendor...devrandom:experiment-devrandom-old-compile
> >
> > This doesn't quite get us to when zcash was announced in January of 2016.
> > To make further progress, I will look into backporting the question-mark
> > operator from
> >
> https://github.com/rust-lang/rust/commit/210dd611aa1bd80ed2f4e663b3c4b87b3cea069a
> > to
> > an earlier nightly.
>
> Not sure how familiar you are with Rust, but FWIW it might be easier to
> just
> mechanically replace the question mark operator with the try! macro. For
> example, this line:
>
> let alpha_g1_s = read_uncompressed(reader)?;
>
> simply becomes:
>
> let alpha_g1_s = try!(read_uncompressed(reader));
>
> This has the advantage of having compatibility with potentially quite old
> versions of Rust.
>

Will try that if the mrustc path continues to be blocked for longer than a
few days.

[zapps-wg] Saving inputs for forensics

[Devrandom via zapps-wg]

Hi Sean,

I think it would be useful if everybody saves their inputs (including boot
USB drive, Compute binary and Rust distribution) for forensics, and
includes a hash of all this in their attestation.

We can later check the binaries, especially Compute using a binary diff
against a more secure tool chain.  In fact, uploading the Compute binaries
starting now may be a good idea.

Re: [zapps-wg] Version of Rust

[Devrandom via zapps-wg]

I'm going to try to compile with older versions, will let you know how it
goes.  Ideally we could get to versions before zcash was announced.

This will be fun, have not done Rust before.  But here are some thoughts
about the Rust compiler after trying to compile it from source:

- the Rust compiler can only be built with itself, which means that you
have to start from a binary, so you might as well trust the binary
- if we start with a really old one, the chances of a targeted attack are
pretty slim
- a general trojan that detects access to /dev/random and reduces entropy
could still be lurking
- the mixing of entropy from the user should mitigate, unless the compiler
can be smart enough to detect even that

BTW, what does the timestamp on crates.io buy us? Looking at the repo, it
looks like they just commit version numbers, but not git hashes of the
source code.


On Thu, Nov 16, 2017 at 4:45 PM Peter Todd  wrote:

> On Thu, Nov 16, 2017 at 01:59:53PM -0700, Sean Bowe via zapps-wg wrote:
> > 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.
>
> Also, if someone does manage to do this, I have a OpenTimestamps Git
> timestamp(1)
> on Rust crates.io crate registry:
>
>
> https://github.com/petertodd/crates.io-index/commit/763a730f2275d69eb13ee8b212fc9aa0d6fe92b5
>
> Secondly the Internet Archive contains quite a bit of uploaded software,
> such
> as Debian install images, and via my Internet Archive timestamp project we
> have
> timestamps from May this year for most of that:
>
>
> https://petertodd.org/2017/carbon-dating-the-internet-archive-with-opentimestamps
>
> While these timestamps would be only one part of an argument as to why a
> given
> compile wasn't backdoored, I think it's worth using cryptographically
> timestamped dependencies over non-timestamped ones when possible.
>
>
> 1) https://petertodd.org/2016/opentimestamps-git-integration
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
>

[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?