nullius [ARCHIVE] on Nostr: đ Original date posted:2018-01-12 đ Original message:On 2018-01-12 at 08:54:12 ...
đ
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>;
đ 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>;