On 2018-01-12 at 08:54:12 +0000, Peter Todd <[email protected]> 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 EDTHomework 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----- <snip pgp stuff> -----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 <do installation>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 [email protected] https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
-- [email protected] | 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
signature.asc
Description: PGP signature
_______________________________________________ bitcoin-dev mailing list [email protected] https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
