Re: [bitcoin-dev] New Bitcoin Core macOS signing key

[nullius <nullius@nym.zone>]

[-- Attachment #1: Type: text/plain, Size: 5216 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]