đ
Original date posted:2018-01-12
đ Original message:On 2018-01-12 at 08:54:12 +0000, Peter Todd <pete at 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 at lists.linuxfoundation.org
>https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
--
nullius at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180112/54009101/attachment-0001.sig>;
nullius [ARCHIVE] /
npub1umâŚk2hgv
2023-06-07 18:09:42
in reply to nevent1qâŚdeyh
Author Public Key
npub1umcywfan64dcuxeycrujenkhh3n3yutyc3x5ewprtjr0c7a7kxqsgk2hgvPublished at
2023-06-07 18:09:42Event JSON
{
"id": "0652a999547521244126d69a59f9c910125551c5749f48426f91f4edee27baee",
"pubkey": "e6f04727b3d55b8e1b24c0f92cced7bc67127164c44d4cb8235c86fc7bbeb181",
"created_at": 1686161382,
"kind": 1,
"tags": [
[
"e",
"2559f60a1d69ff7b5ac64747906b531f710dda88fd230c5f5d15aacc20552c40",
"",
"root"
],
[
"e",
"afb64cc306a9533273ab5ada61ecdaa273b7613283776882f308d8a3af0b89a8",
"",
"reply"
],
[
"p",
"daa2fc676a25e3b5b45644540bcbd1e1168b111427cd0e3cf19c56194fb231aa"
]
],
"content": "đ
Original date posted:2018-01-12\nđ Original message:On 2018-01-12 at 08:54:12 +0000, Peter Todd \u003cpete at petertodd.org\u003e wrote:\n\u003eWhile a clunky way to do it, you can use the `-signer` option to tell \n\u003eOpenSSL to write the signer's certificate to a file. That certificate \n\u003ecan then be compared to the one from the repo, which was still in the \n\u003erepo as of the (signed!) v0.15.1 tag.\n\u003e\n\u003e\n\u003eFun fact: OpenTimestamps has git integration, which means you can \n\u003eextract a OTS proof from 2016 for that certificate from the repo:\n\u003e\n\u003e $ git checkout v0.15.1\n\u003e $ ots git-extract share/certs/BitcoinFoundation_Apple_Cert.pem share/certs/BitcoinFoundation_Apple_Cert.pem.ots 36f60a5d5b1bc9a12b87d6475e3245b8236775e4\n\u003e $ ots verify share/certs/BitcoinFoundation_Apple_Cert.pem.ots\n\u003e Assuming target filename is 'share/certs/BitcoinFoundation_Apple_Cert.pem'\n\u003e Success! Bitcoin attests data existed as of Thu Oct 13 14:08:59 2016 EDT\n\u003e\n\u003eHomework problem: write a paragraph explaining how the proof generated \n\u003eby the above three commands are crypto snakeoil that proved little. :)\n\nIt says, âBitcoin attests data existedâ. Within the scope of those \nthree commands, I donât see any proof of who put it there. Does OTS \ncheck the PGP signatures on *commits* when it does that `git-extract`? \nThe signature on the v0.15.1 tag is irrelevant to that question; and \nFWIW, I donât see *that* signature being verified here, either. \n\nSecond paragraph: Moreover, with the breaking of SHA-1, it *may* be \nfeasible for some scenario to play out involving two different PEMs with \nthe same hash, but different public keys (and thus different \ncorresponding private keys). I donât know off the top of my head if \nsomewhere could be found to stash the magic bits; and the overall \nscenario would need to be a bit convoluted. I think a malicious \ncommitter who lacked access to the signing key *may* be able to create a \ncollision between the real certificate, and a certificate as for which \nhe has the private keyâthen switch them, later. Maybe. I would not \ndiscount the possibility off-hand. OTS would prove nothing, if he had \nthe foresight to obtain timestamps proving that both certificates \nexisted at the appropriate time (which they would need to anyway; it is \nnot a post facto preimage attack).\n\n\u003e[...]\n\u003e\n\u003eWhat's nice about OpenPGP's \"clearsigned\" format is how it ignores \n\u003ewhitespace; a replica of that might be a nice thing for OTS to be able \n\u003eto do too. Though that's on low priority, as there's some tricky design \n\u003echoices(1) to be made about how to nicely nest clearsigned PGP within \n\u003eOTS.\n\u003e\n\u003e\n\u003e1) For example, I recently found a security hole related to clearsigned \n\u003ePGP recently. Basically the issue was that gpg --verify will return \n\u003etrue on a file that looks like the following:\n\u003e\n\u003e 1d7a363ce12430881ec56c9cf1409c49c491043618e598c356e2959040872f5a foo-v2.0.tar.gz\n\u003e -----BEGIN PGP SIGNED MESSAGE-----\n\u003e Hash: SHA256\n\u003e\n\u003e e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855 foo-v1.0.tar.gz\n\u003e -----BEGIN PGP SIGNATURE-----\n\u003e\n\u003e \u003csnip pgp stuff\u003e\n\u003e -----END PGP SIGNATURE-----\n\u003e\n\u003eThe system I was auditing then did something like this to verify that \n\u003ethe file was signed:\n\u003e\n\u003e set -e # exit immediately on error\n\u003e gpg --verify SHA256SUMS.asc\n\u003e cat SHA256SUMS.asc | grep foo-v2.0.tar.gz\n\u003e \u003cdo installation\u003e\n\u003e\n\u003eWhile it makes it a bit less user friendly, the fact that PKCS7's \n\u003eencoding made it impossible to see the message you signed until it's \n\u003ebeen properly verified is a good thing re: security.\n\nPotential solutions using PGP:\n\n0. Donât use clearsigning.\n\n1. Use a detached signature.\n\n2. Use `gpg --verify -o -` and pipe that to `grep`, rather than \nillogically separating verification from use of data. (By the way, \nwhere is the *hash* verified? Was `grep` piped to `sha256sum -c`?)\n\n3. Have shell scripts written by somebody who knows how to think about \nsecurity, and/or who knows how to RTFM; quoting gpg(1):\n\n\u003eNote: When verifying a cleartext signature, gpg verifies only what \n\u003emakes up the cleartext signed data and not any extra data outside of \n\u003ethe cleartext signature or the header lines directly following the dash \n\u003emarker line. The option --output may be used to write out the actual \n\u003esigned data, but there are other pitfalls with this format as well. It \n\u003eis suggested to avoid cleartext signatures in favor of detached \n\u003esignatures.\n\n4. Obtain an audit from Peter Todd.\n\n\u003eAnd yes, I checked: Bitcoin Core's contrib/verifybinaries/verify.sh \n\u003eisn't vulnerable to this mistake. :)\n\nP.S., oh my! *Unsigned data:*\n\n\u003e_______________________________________________\n\u003ebitcoin-dev mailing list\n\u003ebitcoin-dev at lists.linuxfoundation.org\n\u003ehttps://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\n-- \nnullius at nym.zone | PGP ECC: 0xC2E91CD74A4C57A105F6C21B5A00591B2F307E0C\nBitcoin: bc1qcash96s5jqppzsp8hy8swkggf7f6agex98an7h | (Segwit nested:\n3NULL3ZCUXr7RDLxXeLPDMZDZYxuaYkCnG) (PGP RSA: 0x36EBB4AB699A10EE)\nââIf youâre not doing anything wrong, you have nothing to hide.â\nNo! Because I do nothing wrong, I have nothing to show.â â nullius\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 228 bytes\nDesc: not available\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180112/54009101/attachment-0001.sig\u003e",
"sig": "32b88a5b8fd69d2a12c0364aaebb87e36a55835ca8f500bfc02db41043bad3a420525ec0cefbb3eaf6bd3ba8cb8b511a867bd4982cdb0f66657f32a8fb32217f"
}