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 >OpenSSL to write the signer's certificate to a file. That certificate >can then be compared to the one from the repo, which was still in the >repo as of the (signed!) v0.15.1 tag. > > >Fun fact: OpenTimestamps has git integration, which means you can >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/certs/BitcoinFoundation_Apple_Cert.pem.ots 36f60a5d5b1bc9a12b87d6475e3245b8236775e4 > $ 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 EDT > >Homework problem: write a paragraph explaining how the proof generated >by the above three commands are crypto snakeoil that proved little. :) It says, “Bitcoin attests data existed”. Within the scope of those three commands, I don’t see any proof of who put it there. Does OTS check the PGP signatures on *commits* when it does that `git-extract`? The signature on the v0.15.1 tag is irrelevant to that question; and FWIW, I don’t see *that* signature being verified here, either. Second paragraph: Moreover, with the breaking of SHA-1, it *may* be feasible for some scenario to play out involving two different PEMs with the same hash, but different public keys (and thus different corresponding private keys). I don’t know off the top of my head if somewhere could be found to stash the magic bits; and the overall scenario would need to be a bit convoluted. I think a malicious committer who lacked access to the signing key *may* be able to create a collision between the real certificate, and a certificate as for which he has the private key—then switch them, later. Maybe. I would not discount the possibility off-hand. OTS would prove nothing, if he had the foresight to obtain timestamps proving that both certificates existed at the appropriate time (which they would need to anyway; it is not a post facto preimage attack). >[...] > >What's nice about OpenPGP's "clearsigned" format is how it ignores >whitespace; a replica of that might be a nice thing for OTS to be able >to do too. Though that's on low priority, as there's some tricky design >choices(1) to be made about how to nicely nest clearsigned PGP within >OTS. > > >1) For example, I recently found a security hole related to clearsigned >PGP recently. Basically the issue was that gpg --verify will return >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 >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 >encoding made it impossible to see the message you signed until it's >been properly verified is a good thing re: security. Potential solutions using PGP: 0. Don’t use clearsigning. 1. Use a detached signature. 2. Use `gpg --verify -o -` and pipe that to `grep`, rather than illogically separating verification from use of data. (By the way, where is the *hash* verified? Was `grep` piped to `sha256sum -c`?) 3. Have shell scripts written by somebody who knows how to think about security, and/or who knows how to RTFM; quoting gpg(1): >Note: When verifying a cleartext signature, gpg verifies only what >makes up the cleartext signed data and not any extra data outside of >the cleartext signature or the header lines directly following the dash >marker line. The option --output may be used to write out the actual >signed data, but there are other pitfalls with this format as well. It >is suggested to avoid cleartext signatures in favor of detached >signatures. 4. Obtain an audit from Peter Todd. >And yes, I checked: Bitcoin Core's contrib/verifybinaries/verify.sh >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 -- nullius@nym.zone | PGP ECC: 0xC2E91CD74A4C57A105F6C21B5A00591B2F307E0C Bitcoin: bc1qcash96s5jqppzsp8hy8swkggf7f6agex98an7h | (Segwit nested: 3NULL3ZCUXr7RDLxXeLPDMZDZYxuaYkCnG) (PGP RSA: 0x36EBB4AB699A10EE) “‘If you’re not doing anything wrong, you have nothing to hide.’ No! Because I do nothing wrong, I have nothing to show.” — nullius