Date: Fri, 12 Jan 2018 10:14:11 +0000
From: nullius <nullius@nym.zone>
To: Peter Todd <pete@petertodd.org>,
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Message-ID: <23bf1f30b85d0f23d6c9eab93f1d8e06@nym.zone>
References: <CAApLimjGy6TCd7kg8RKkuGqAZTfcuNSfsrDowEsEcbEnM_0rzg@mail.gmail.com>
	<20180112085412.GA8088@savin.petertodd.org>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="bqrva4rmndb23fn6"
Content-Disposition: inline
In-Reply-To: <20180112085412.GA8088@savin.petertodd.org>
Subject: Re: [bitcoin-dev] New Bitcoin Core macOS signing key
Precedence: list


--bqrva4rmndb23fn6
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On 2018-01-12 at 08:54:12 +0000, Peter Todd <pete@petertodd.org> wrote:
>While a clunky way to do it, you can use the `-signer` option to tell=20
>OpenSSL to write the signer's certificate to a file. That certificate=20
>can then be compared to the one from the repo, which was still in the=20
>repo as of the (signed!) v0.15.1 tag.
>
>
>Fun fact: OpenTimestamps has git integration, which means you can=20
>extract a OTS proof from 2016 for that certificate from the repo:
>
>    $ git checkout v0.15.1
>    $ ots git-extract share/certs/BitcoinFoundation_Apple_Cert.pem share/c=
erts/BitcoinFoundation_Apple_Cert.pem.ots 36f60a5d5b1bc9a12b87d6475e3245b82=
36775e4
>    $ ots verify share/certs/BitcoinFoundation_Apple_Cert.pem.ots
>    Assuming target filename is 'share/certs/BitcoinFoundation_Apple_Cert.=
pem'
>    Success! Bitcoin attests data existed as of Thu Oct 13 14:08:59 2016 E=
DT
>
>Homework problem: write a paragraph explaining how the proof generated=20
>by the above three commands are crypto snakeoil that proved little. :)

It says, =E2=80=9CBitcoin attests data existed=E2=80=9D.  Within the scope =
of those=20
three commands, I don=E2=80=99t see any proof of who put it there.  Does OT=
S=20
check the PGP signatures on *commits* when it does that `git-extract`? =20
The signature on the v0.15.1 tag is irrelevant to that question; and=20
FWIW, I don=E2=80=99t see *that* signature being verified here, either. =20

Second paragraph:  Moreover, with the breaking of SHA-1, it *may* be=20
feasible for some scenario to play out involving two different PEMs with=20
the same hash, but different public keys (and thus different=20
corresponding private keys).  I don=E2=80=99t know off the top of my head i=
f=20
somewhere could be found to stash the magic bits; and the overall=20
scenario would need to be a bit convoluted.  I think a malicious=20
committer who lacked access to the signing key *may* be able to create a=20
collision between the real certificate, and a certificate as for which=20
he has the private key=E2=80=94then switch them, later.  Maybe.  I would no=
t=20
discount the possibility off-hand.  OTS would prove nothing, if he had=20
the foresight to obtain timestamps proving that both certificates=20
existed at the appropriate time (which they would need to anyway; it is=20
not a post facto preimage attack).

>[...]
>
>What's nice about OpenPGP's "clearsigned" format is how it ignores=20
>whitespace; a replica of that might be a nice thing for OTS to be able=20
>to do too. Though that's on low priority, as there's some tricky design=20
>choices(1) to be made about how to nicely nest clearsigned PGP within=20
>OTS.
>
>
>1) For example, I recently found a security hole related to clearsigned=20
>PGP recently. Basically the issue was that gpg --verify will return=20
>true on a file that looks like the following:
>
>    1d7a363ce12430881ec56c9cf1409c49c491043618e598c356e2959040872f5a  foo-=
v2.0.tar.gz
>    -----BEGIN PGP SIGNED MESSAGE-----
>    Hash: SHA256
>
>    e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855  foo-=
v1.0.tar.gz
>    -----BEGIN PGP SIGNATURE-----
>
>    <snip pgp stuff>
>    -----END PGP SIGNATURE-----
>
>The system I was auditing then did something like this to verify that=20
>the file was signed:
>
>    set -e # exit immediately on error
>    gpg --verify SHA256SUMS.asc
>    cat SHA256SUMS.asc | grep foo-v2.0.tar.gz
>    <do installation>
>
>While it makes it a bit less user friendly, the fact that PKCS7's=20
>encoding made it impossible to see the message you signed until it's=20
>been properly verified is a good thing re: security.

Potential solutions using PGP:

0. Don=E2=80=99t use clearsigning.

1. Use a detached signature.

2. Use `gpg --verify -o -` and pipe that to `grep`, rather than=20
illogically separating verification from use of data.  (By the way,=20
where is the *hash* verified?  Was `grep` piped to `sha256sum -c`?)

3. Have shell scripts written by somebody who knows how to think about=20
security, and/or who knows how to RTFM; quoting gpg(1):

>Note: When verifying a cleartext signature, gpg verifies only what =20
>makes up the cleartext signed data and not any extra data outside of=20
>the cleartext signature or the header lines directly following the dash=20
>marker line.  The option --output may be used to write out the actual=20
>signed data, but there are other pitfalls with this format as well.  It=20
>is suggested to avoid cleartext signatures in favor of detached=20
>signatures.

4. Obtain an audit from Peter Todd.

>And yes, I checked: Bitcoin Core's contrib/verifybinaries/verify.sh=20
>isn't vulnerable to this mistake. :)

P.S., oh my!  *Unsigned data:*

>_______________________________________________
>bitcoin-dev mailing list
>bitcoin-dev@lists.linuxfoundation.org
>https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

--=20
nullius@nym.zone | PGP ECC: 0xC2E91CD74A4C57A105F6C21B5A00591B2F307E0C
Bitcoin: bc1qcash96s5jqppzsp8hy8swkggf7f6agex98an7h | (Segwit nested:
3NULL3ZCUXr7RDLxXeLPDMZDZYxuaYkCnG)  (PGP RSA: 0x36EBB4AB699A10EE)
=E2=80=9C=E2=80=98If you=E2=80=99re not doing anything wrong, you have noth=
ing to hide.=E2=80=99
No!  Because I do nothing wrong, I have nothing to show.=E2=80=9D =E2=80=94=
 nullius

--bqrva4rmndb23fn6
Content-Type: application/pgp-signature; name="signature.asc"

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

iHUEARYKAB0WIQSNOMR84IlYpr/EF5vEJ5MVn575SQUCWliKcQAKCRDEJ5MVn575
Se0DAQCr+vGN5jC46zJKOFdLkJZ/yasU1HF3wobwmn+alTwjhQEA7n8OFP+D0FYt
7MtOm6SG0SOVICGZIz9ISBTArdR1kQ8=
=hrgm
-----END PGP SIGNATURE-----

--bqrva4rmndb23fn6--