From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 22D24EBF for ; Fri, 12 Jan 2018 10:15:06 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from mx2.mailbox.org (mx2.mailbox.org [80.241.60.215]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 2E958D0 for ; Fri, 12 Jan 2018 10:15:03 +0000 (UTC) Received: from smtp2.mailbox.org (smtp2.mailbox.org [80.241.60.241]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx2.mailbox.org (Postfix) with ESMTPS id 118924117F; Fri, 12 Jan 2018 11:15:00 +0100 (CET) X-Virus-Scanned: amavisd-new at heinlein-support.de Received: from smtp2.mailbox.org ([80.241.60.241]) by spamfilter02.heinlein-hosting.de (spamfilter02.heinlein-hosting.de [80.241.56.116]) (amavisd-new, port 10030) with ESMTP id b0ApjvlmBZYK; Fri, 12 Jan 2018 11:14:55 +0100 (CET) Date: Fri, 12 Jan 2018 10:14:11 +0000 From: nullius To: Peter Todd , Bitcoin Protocol Discussion Message-ID: <23bf1f30b85d0f23d6c9eab93f1d8e06@nym.zone> References: <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> X-Spam-Status: No, score=-0.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW, URIBL_BLACK autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Mailman-Approved-At: Fri, 12 Jan 2018 10:33:06 +0000 Subject: Re: [bitcoin-dev] New Bitcoin Core macOS signing key X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jan 2018 10:15:06 -0000 --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 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----- > > > -----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 > > >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--