📅 Original date posted:2018-01-31
📝 Original message:A public key was published recently for future macOS releases. Sadly,
that key was created the wrong way (iPhone OS instead of macOS), so
another had to be generated.
The new, working pubkey for Bitcoin Core releases starting with
0.16.0rc1 is included in the message below. That message is signed
with the key mentioned in the previous mail.
It can be verified with: openssl smime -verify -noverify -in msg.pem
Sorry for the noise.
-----BEGIN PKCS7-----
MIIPbQYJKoZIhvcNAQcCoIIPXjCCD1oCAQExCzAJBgUrDgMCGgUAMIIC5gYJKoZI
hvcNAQcBoIIC1wSCAtNBIHB1YmxpYyBrZXkgd2FzIHB1Ymxpc2hlZCByZWNlbnRs
eSBmb3IgZnV0dXJlIG1hY09TIHJlbGVhc2VzLg0KDQpTYWRseSwgdGhlIHB1Ymxp
c2hlZCBrZXkgd2FzIGNyZWF0ZWQgdGhlIHdyb25nIHdheSAoaVBob25lIE9TIGlu
c3RlYWQgb2YgbWFjT1MpLCBzbyBhbm90aGVyIGhhZCB0byBiZSByZXF1ZXN0ZWQu
DQoNClRoZSBuZXcsIHdvcmtpbmcgcHVia2V5IGZvciBCaXRjb2luIENvcmUgcmVs
ZWFzZXMgc3RhcnRpbmcgd2l0aCAwLjE2LjByYzEgaXM6DQoNCi0tLS0tQkVHSU4g
UFVCTElDIEtFWS0tLS0tDQpNSUlCSWpBTkJna3Foa2lHOXcwQkFRRUZBQU9DQVE4
QU1JSUJDZ0tDQVFFQXF4aWJEZ2pBT09WVXBTY3pVMnBqDQp0UEVpQ0lZeXl2V21E
N2VidGhQbzI5WG9xMUJqYWJGNDlCZ3diNkZFaU1haFN5UTY4ZklMSUhDanJ5SUo4
RUN1DQpROFJWbVF3cGdhKzV0OTZiMEM5emN5WTFhcSsrRzIyMVNqNmFpUmVveXZw
cHIrZ2poNmNPbktEc1B0Z2pUcGdiDQovOUhuMmtwYzFmZ000ZkRFMlQ2VXZHVHMw
d3d5dWNvL21ya0s1LzEySCtqZUE3QXVNcjBLQTBVSktSS1VOenFhDQo4QjlLalFF
ektaRGVVVHRYak9vSmIyNkRQU3hCbXBGd25zWSs2aHBjeFZSSmphNG1FYzRFYnIy
b2gxSmVORU5uDQp4WXR3MHRWVWczTUwvWlI2WU9qQVpMY0V0cW5IR2ZOZXVRazJX
Vm1pYy9JY3d4VEM0cUk4MnFROGgxQnFpY3pRDQo4UUlEQVFBQg0KLS0tLS1FTkQg
UFVCTElDIEtFWS0tLS0tDQqgggnZMIIFzTCCBLWgAwIBAgIId5kUM+xSbWMwDQYJ
KoZIhvcNAQELBQAwgZYxCzAJBgNVBAYTAlVTMRMwEQYDVQQKDApBcHBsZSBJbmMu
MSwwKgYDVQQLDCNBcHBsZSBXb3JsZHdpZGUgRGV2ZWxvcGVyIFJlbGF0aW9uczFE
MEIGA1UEAww7QXBwbGUgV29ybGR3aWRlIERldmVsb3BlciBSZWxhdGlvbnMgQ2Vy
dGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNMTgwMTEwMjAyNTA1WhcNMTkwMTEwMjAy
NTA1WjCBwDEaMBgGCgmSJomT8ixkAQEMCllaQzdXSDNNUlUxUDBOBgNVBAMMR2lQ
aG9uZSBEaXN0cmlidXRpb246IEJpdGNvaW4gQ29yZSBDb2RlIFNpZ25pbmcgQXNz
b2NpYXRpb24gKFlaQzdXSDNNUlUpMRMwEQYDVQQLDApZWkM3V0gzTVJVMS4wLAYD
VQQKDCVCaXRjb2luIENvcmUgQ29kZSBTaWduaW5nIEFzc29jaWF0aW9uMQswCQYD
VQQGEwJVUzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKsYmw4IwDjl
VKUnM1NqY7TxIgiGMsr1pg+3m7YT6NvV6KtQY2mxePQYMG+hRIjGoUskOvHyCyBw
o68iCfBArkPEVZkMKYGvubfem9Avc3MmNWqvvhtttUo+mokXqMr6aa/oI4enDpyg
7D7YI06YG//R59pKXNX4DOHwxNk+lLxk7NMMMrnKP5q5Cuf9dh/o3gOwLjK9CgNF
CSkSlDc6mvAfSo0BMymQ3lE7V4zqCW9ugz0sQZqRcJ7GPuoaXMVUSY2uJhHOBG69
qIdSXjRDZ8WLcNLVVINzC/2UemDowGS3BLapxxnzXrkJNllZonPyHMMUwuKiPNqk
PIdQaonM0PECAwEAAaOCAfEwggHtMD8GCCsGAQUFBwEBBDMwMTAvBggrBgEFBQcw
AYYjaHR0cDovL29jc3AuYXBwbGUuY29tL29jc3AwMy13d2RyMTEwHQYDVR0OBBYE
FNOBKRRpuWarZwT6owhUtiOP6lbSMAwGA1UdEwEB/wQCMAAwHwYDVR0jBBgwFoAU
iCcXCam2GGCL7Ou69kdZxVJUo7cwggEdBgNVHSAEggEUMIIBEDCCAQwGCSqGSIb3
Y2QFATCB/jCBwwYIKwYBBQUHAgIwgbYMgbNSZWxpYW5jZSBvbiB0aGlzIGNlcnRp
ZmljYXRlIGJ5IGFueSBwYXJ0eSBhc3N1bWVzIGFjY2VwdGFuY2Ugb2YgdGhlIHRo
ZW4gYXBwbGljYWJsZSBzdGFuZGFyZCB0ZXJtcyBhbmQgY29uZGl0aW9ucyBvZiB1
c2UsIGNlcnRpZmljYXRlIHBvbGljeSBhbmQgY2VydGlmaWNhdGlvbiBwcmFjdGlj
ZSBzdGF0ZW1lbnRzLjA2BggrBgEFBQcCARYqaHR0cDovL3d3dy5hcHBsZS5jb20v
Y2VydGlmaWNhdGVhdXRob3JpdHkvMA4GA1UdDwEB/wQEAwIHgDAWBgNVHSUBAf8E
DDAKBggrBgEFBQcDAzATBgoqhkiG92NkBgEEAQH/BAIFADANBgkqhkiG9w0BAQsF
AAOCAQEARvNgy5mhFqZsI5JGgn6HSR/eQIXjuoGyOivOa6+uCb5qcrSjSR+PSj7D
K/SBxrz+sVgKvwQ3buhv3BJnURmbYtEmqRr60G+yZE6xNpDMEyZyEM7aT6R9zBMX
++5mwqq5Ip57Mq8yB+pGTzSCBUAat6qiMBUkJBa+F/fk+vXZxgKAfKGMEfALLR5j
Rnwadg2CoTng47Mt4gzuGqjRSJH2vlB44GzRiFoJjXJOJGZ0hdagXl1ARTKul1NF
QukGMeJa1xlXzEk2K1sT7inGHEHTO5KD4RyyVFaDTnhWtvDfmDZt5R/Ipfc7KMmc
dObDKqWe/TGoKM5noj3dvafhNFZ9mDCCBAQwggLsoAMCAQICCBh6qajCliEMMA0G
CSqGSIb3DQEBCwUAMGIxCzAJBgNVBAYTAlVTMRMwEQYDVQQKEwpBcHBsZSBJbmMu
MSYwJAYDVQQLEx1BcHBsZSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEWMBQGA1UE
AxMNQXBwbGUgUm9vdCBDQTAeFw0xMjAyMDEyMjEyMTVaFw0yNzAyMDEyMjEyMTVa
MHkxLTArBgNVBAMMJERldmVsb3BlciBJRCBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0
eTEmMCQGA1UECwwdQXBwbGUgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxEzARBgNV
BAoMCkFwcGxlIEluYy4xCzAJBgNVBAYTAlVTMIIBIjANBgkqhkiG9w0BAQEFAAOC
AQ8AMIIBCgKCAQEAiXZPBluaQe6lIysCo1/Xcz/ANbCLhAo/BiR/p5U/608Ok6+0
DtDIPuVtGLMf6IlHv9cJCOT/VpgpFeeUnbk1owrNtMDh4mD0yuwpeEVpaWBrX4qS
/J4j5jrCIrMxTxy68rY0WULusKkCAxiRBLazeC4zH4BFDUVvuw5aW38659gI1wsO
Mm37hjbkbKvEEYpwhCaqn0TR8bjGe5QXm0j3C1gWuiPFnxU5fspdwzJfD+BSf0Dq
vqwIZJVbyRqc5YDKH2pEHGw+xLAmHx3se69eoGo9R6lYEjE/IHYobR0csMJOEWkm
i8vW0BGCyU4P8VZ00NkIS2Z4oqusp+LSTIdZyQIDAQABo4GmMIGjMB0GA1UdDgQW
BBRXF+2iz9x8mKEQ4Py+hy0s8uMXVDAPBgNVHRMBAf8EBTADAQH/MB8GA1UdIwQY
MBaAFCvQaUeUdgn+9GuNLkCm90dNfwheMC4GA1UdHwQnMCUwI6AhoB+GHWh0dHA6
Ly9jcmwuYXBwbGUuY29tL3Jvb3QuY3JsMA4GA1UdDwEB/wQEAwIBhjAQBgoqhkiG
92NkBgIGBAIFADANBgkqhkiG9w0BAQsFAAOCAQEAQjl0a6HcxqSPNyqMsx0KRLyV
LH+8WbisYfsHkJIyudS/O8FQOWpEdKLsWx9w5ardS2wcI3EtX9HFk77um4pwZYKd
FuMaEBeJLajN/Qx4WEkMKH8z7gB6G7R2rLa1u0/fqBudyBmXSgtWZy/CPrazxIM6
8HdtdMQuI1HumqUDb2D0pUinBsK7WuIfH0ZFfuSX9ScQtyAicm9y2sZQdcU9JY9d
owDpnzaMSDmPszvqkIAulZpg9HjO9A4KUz6i+k/YHq6ElY0yvFZNiel4GOCsmkK6
ekYbhKKJzhToiNFYi/auVsQsBSpFrwvZS6kCDzSsiMdhVYlEySdzB+6C5U71cDGC
An8wggJ7AgEBMIGjMIGWMQswCQYDVQQGEwJVUzETMBEGA1UECgwKQXBwbGUgSW5j
LjEsMCoGA1UECwwjQXBwbGUgV29ybGR3aWRlIERldmVsb3BlciBSZWxhdGlvbnMx
RDBCBgNVBAMMO0FwcGxlIFdvcmxkd2lkZSBEZXZlbG9wZXIgUmVsYXRpb25zIENl
cnRpZmljYXRpb24gQXV0aG9yaXR5Agh3mRQz7FJtYzAJBgUrDgMCGgUAoIGxMBgG
CSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE4MDIwMTAx
MTExNFowIwYJKoZIhvcNAQkEMRYEFNKi/xYPqnN6zp/RogVZBZ3ICGOBMFIGCSqG
SIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3
DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMA0GCSqGSIb3DQEBAQUABIIB
AJQtrcrRd/3PLS9rhey0RyU1ZRnuB4Ib+y/wAan3k+fRNpA70F9kaxxcme78eqho
HH5rvizY4InvrG1wjtpYeickMHp+s0E51j1AbVxOgZ/UiEgjLRq9Dv5OCPgKoLaB
lsyCj41baXvlqzXZ8RaP7Li2SPLpdksqLE5yegiN+yMIiEPfNAtmaRLN3CNnbbMf
X1bF4ifgyhy3P1VGPPk+WTiQyu0VqySrlhz0Ux9+acB/TFUrymFEKxJ/7bM//4nL
UpEQVlnj9rl3OYzhYgDsQgz0kGU+6UG7Iw6gB9xFAMeE/1Y5Xrs2UdjBVC9hkSy8
r1+2rPF1yixiWjiORNk4kyU=
-----END PKCS7-----
Regards,
Cory
On Fri, Jan 12, 2018 at 5:14 AM, nullius via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> 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
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
Cory Fields [ARCHIVE] /
npub19r…yj32s
2023-06-07 18:10:27
in reply to nevent1q…vtj7
Author Public Key
npub19r53ufymeycp9wzk3yzru55y5u46e4vva2lj7nak4zrn6yhrna7qsyj32sPublished at
2023-06-07 18:10:27Event JSON
{
"id": "7adaedc662b1d6c5b07fed2863bfebb59ad9159c1a17de880eeb9eef9147a49b",
"pubkey": "28e91e249bc93012b85689043e5284a72bacd58ceabf2f4fb6a8873d12e39f7c",
"created_at": 1686161427,
"kind": 1,
"tags": [
[
"e",
"2b04994cd4cabad2d8f7e70e828182144348910761cb6ba53ecc436fe095eca2",
"",
"reply"
],
[
"p",
"a23dbf6c6cc83e14cc3df4e56cc71845f611908084cfe620e83e40c06ccdd3d0"
]
],
"content": "📅 Original date posted:2018-01-31\n📝 Original message:A public key was published recently for future macOS releases. Sadly,\nthat key was created the wrong way (iPhone OS instead of macOS), so\nanother had to be generated.\n\nThe new, working pubkey for Bitcoin Core releases starting with\n0.16.0rc1 is included in the message below. That message is signed\nwith the key mentioned in the previous mail.\nIt can be verified with: openssl smime -verify -noverify -in msg.pem\n\nSorry for the noise.\n\n-----BEGIN PKCS7-----\nMIIPbQYJKoZIhvcNAQcCoIIPXjCCD1oCAQExCzAJBgUrDgMCGgUAMIIC5gYJKoZI\nhvcNAQcBoIIC1wSCAtNBIHB1YmxpYyBrZXkgd2FzIHB1Ymxpc2hlZCByZWNlbnRs\neSBmb3IgZnV0dXJlIG1hY09TIHJlbGVhc2VzLg0KDQpTYWRseSwgdGhlIHB1Ymxp\nc2hlZCBrZXkgd2FzIGNyZWF0ZWQgdGhlIHdyb25nIHdheSAoaVBob25lIE9TIGlu\nc3RlYWQgb2YgbWFjT1MpLCBzbyBhbm90aGVyIGhhZCB0byBiZSByZXF1ZXN0ZWQu\nDQoNClRoZSBuZXcsIHdvcmtpbmcgcHVia2V5IGZvciBCaXRjb2luIENvcmUgcmVs\nZWFzZXMgc3RhcnRpbmcgd2l0aCAwLjE2LjByYzEgaXM6DQoNCi0tLS0tQkVHSU4g\nUFVCTElDIEtFWS0tLS0tDQpNSUlCSWpBTkJna3Foa2lHOXcwQkFRRUZBQU9DQVE4\nQU1JSUJDZ0tDQVFFQXF4aWJEZ2pBT09WVXBTY3pVMnBqDQp0UEVpQ0lZeXl2V21E\nN2VidGhQbzI5WG9xMUJqYWJGNDlCZ3diNkZFaU1haFN5UTY4ZklMSUhDanJ5SUo4\nRUN1DQpROFJWbVF3cGdhKzV0OTZiMEM5emN5WTFhcSsrRzIyMVNqNmFpUmVveXZw\ncHIrZ2poNmNPbktEc1B0Z2pUcGdiDQovOUhuMmtwYzFmZ000ZkRFMlQ2VXZHVHMw\nd3d5dWNvL21ya0s1LzEySCtqZUE3QXVNcjBLQTBVSktSS1VOenFhDQo4QjlLalFF\nektaRGVVVHRYak9vSmIyNkRQU3hCbXBGd25zWSs2aHBjeFZSSmphNG1FYzRFYnIy\nb2gxSmVORU5uDQp4WXR3MHRWVWczTUwvWlI2WU9qQVpMY0V0cW5IR2ZOZXVRazJX\nVm1pYy9JY3d4VEM0cUk4MnFROGgxQnFpY3pRDQo4UUlEQVFBQg0KLS0tLS1FTkQg\nUFVCTElDIEtFWS0tLS0tDQqgggnZMIIFzTCCBLWgAwIBAgIId5kUM+xSbWMwDQYJ\nKoZIhvcNAQELBQAwgZYxCzAJBgNVBAYTAlVTMRMwEQYDVQQKDApBcHBsZSBJbmMu\nMSwwKgYDVQQLDCNBcHBsZSBXb3JsZHdpZGUgRGV2ZWxvcGVyIFJlbGF0aW9uczFE\nMEIGA1UEAww7QXBwbGUgV29ybGR3aWRlIERldmVsb3BlciBSZWxhdGlvbnMgQ2Vy\ndGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNMTgwMTEwMjAyNTA1WhcNMTkwMTEwMjAy\nNTA1WjCBwDEaMBgGCgmSJomT8ixkAQEMCllaQzdXSDNNUlUxUDBOBgNVBAMMR2lQ\naG9uZSBEaXN0cmlidXRpb246IEJpdGNvaW4gQ29yZSBDb2RlIFNpZ25pbmcgQXNz\nb2NpYXRpb24gKFlaQzdXSDNNUlUpMRMwEQYDVQQLDApZWkM3V0gzTVJVMS4wLAYD\nVQQKDCVCaXRjb2luIENvcmUgQ29kZSBTaWduaW5nIEFzc29jaWF0aW9uMQswCQYD\nVQQGEwJVUzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKsYmw4IwDjl\nVKUnM1NqY7TxIgiGMsr1pg+3m7YT6NvV6KtQY2mxePQYMG+hRIjGoUskOvHyCyBw\no68iCfBArkPEVZkMKYGvubfem9Avc3MmNWqvvhtttUo+mokXqMr6aa/oI4enDpyg\n7D7YI06YG//R59pKXNX4DOHwxNk+lLxk7NMMMrnKP5q5Cuf9dh/o3gOwLjK9CgNF\nCSkSlDc6mvAfSo0BMymQ3lE7V4zqCW9ugz0sQZqRcJ7GPuoaXMVUSY2uJhHOBG69\nqIdSXjRDZ8WLcNLVVINzC/2UemDowGS3BLapxxnzXrkJNllZonPyHMMUwuKiPNqk\nPIdQaonM0PECAwEAAaOCAfEwggHtMD8GCCsGAQUFBwEBBDMwMTAvBggrBgEFBQcw\nAYYjaHR0cDovL29jc3AuYXBwbGUuY29tL29jc3AwMy13d2RyMTEwHQYDVR0OBBYE\nFNOBKRRpuWarZwT6owhUtiOP6lbSMAwGA1UdEwEB/wQCMAAwHwYDVR0jBBgwFoAU\niCcXCam2GGCL7Ou69kdZxVJUo7cwggEdBgNVHSAEggEUMIIBEDCCAQwGCSqGSIb3\nY2QFATCB/jCBwwYIKwYBBQUHAgIwgbYMgbNSZWxpYW5jZSBvbiB0aGlzIGNlcnRp\nZmljYXRlIGJ5IGFueSBwYXJ0eSBhc3N1bWVzIGFjY2VwdGFuY2Ugb2YgdGhlIHRo\nZW4gYXBwbGljYWJsZSBzdGFuZGFyZCB0ZXJtcyBhbmQgY29uZGl0aW9ucyBvZiB1\nc2UsIGNlcnRpZmljYXRlIHBvbGljeSBhbmQgY2VydGlmaWNhdGlvbiBwcmFjdGlj\nZSBzdGF0ZW1lbnRzLjA2BggrBgEFBQcCARYqaHR0cDovL3d3dy5hcHBsZS5jb20v\nY2VydGlmaWNhdGVhdXRob3JpdHkvMA4GA1UdDwEB/wQEAwIHgDAWBgNVHSUBAf8E\nDDAKBggrBgEFBQcDAzATBgoqhkiG92NkBgEEAQH/BAIFADANBgkqhkiG9w0BAQsF\nAAOCAQEARvNgy5mhFqZsI5JGgn6HSR/eQIXjuoGyOivOa6+uCb5qcrSjSR+PSj7D\nK/SBxrz+sVgKvwQ3buhv3BJnURmbYtEmqRr60G+yZE6xNpDMEyZyEM7aT6R9zBMX\n++5mwqq5Ip57Mq8yB+pGTzSCBUAat6qiMBUkJBa+F/fk+vXZxgKAfKGMEfALLR5j\nRnwadg2CoTng47Mt4gzuGqjRSJH2vlB44GzRiFoJjXJOJGZ0hdagXl1ARTKul1NF\nQukGMeJa1xlXzEk2K1sT7inGHEHTO5KD4RyyVFaDTnhWtvDfmDZt5R/Ipfc7KMmc\ndObDKqWe/TGoKM5noj3dvafhNFZ9mDCCBAQwggLsoAMCAQICCBh6qajCliEMMA0G\nCSqGSIb3DQEBCwUAMGIxCzAJBgNVBAYTAlVTMRMwEQYDVQQKEwpBcHBsZSBJbmMu\nMSYwJAYDVQQLEx1BcHBsZSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEWMBQGA1UE\nAxMNQXBwbGUgUm9vdCBDQTAeFw0xMjAyMDEyMjEyMTVaFw0yNzAyMDEyMjEyMTVa\nMHkxLTArBgNVBAMMJERldmVsb3BlciBJRCBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0\neTEmMCQGA1UECwwdQXBwbGUgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxEzARBgNV\nBAoMCkFwcGxlIEluYy4xCzAJBgNVBAYTAlVTMIIBIjANBgkqhkiG9w0BAQEFAAOC\nAQ8AMIIBCgKCAQEAiXZPBluaQe6lIysCo1/Xcz/ANbCLhAo/BiR/p5U/608Ok6+0\nDtDIPuVtGLMf6IlHv9cJCOT/VpgpFeeUnbk1owrNtMDh4mD0yuwpeEVpaWBrX4qS\n/J4j5jrCIrMxTxy68rY0WULusKkCAxiRBLazeC4zH4BFDUVvuw5aW38659gI1wsO\nMm37hjbkbKvEEYpwhCaqn0TR8bjGe5QXm0j3C1gWuiPFnxU5fspdwzJfD+BSf0Dq\nvqwIZJVbyRqc5YDKH2pEHGw+xLAmHx3se69eoGo9R6lYEjE/IHYobR0csMJOEWkm\ni8vW0BGCyU4P8VZ00NkIS2Z4oqusp+LSTIdZyQIDAQABo4GmMIGjMB0GA1UdDgQW\nBBRXF+2iz9x8mKEQ4Py+hy0s8uMXVDAPBgNVHRMBAf8EBTADAQH/MB8GA1UdIwQY\nMBaAFCvQaUeUdgn+9GuNLkCm90dNfwheMC4GA1UdHwQnMCUwI6AhoB+GHWh0dHA6\nLy9jcmwuYXBwbGUuY29tL3Jvb3QuY3JsMA4GA1UdDwEB/wQEAwIBhjAQBgoqhkiG\n92NkBgIGBAIFADANBgkqhkiG9w0BAQsFAAOCAQEAQjl0a6HcxqSPNyqMsx0KRLyV\nLH+8WbisYfsHkJIyudS/O8FQOWpEdKLsWx9w5ardS2wcI3EtX9HFk77um4pwZYKd\nFuMaEBeJLajN/Qx4WEkMKH8z7gB6G7R2rLa1u0/fqBudyBmXSgtWZy/CPrazxIM6\n8HdtdMQuI1HumqUDb2D0pUinBsK7WuIfH0ZFfuSX9ScQtyAicm9y2sZQdcU9JY9d\nowDpnzaMSDmPszvqkIAulZpg9HjO9A4KUz6i+k/YHq6ElY0yvFZNiel4GOCsmkK6\nekYbhKKJzhToiNFYi/auVsQsBSpFrwvZS6kCDzSsiMdhVYlEySdzB+6C5U71cDGC\nAn8wggJ7AgEBMIGjMIGWMQswCQYDVQQGEwJVUzETMBEGA1UECgwKQXBwbGUgSW5j\nLjEsMCoGA1UECwwjQXBwbGUgV29ybGR3aWRlIERldmVsb3BlciBSZWxhdGlvbnMx\nRDBCBgNVBAMMO0FwcGxlIFdvcmxkd2lkZSBEZXZlbG9wZXIgUmVsYXRpb25zIENl\ncnRpZmljYXRpb24gQXV0aG9yaXR5Agh3mRQz7FJtYzAJBgUrDgMCGgUAoIGxMBgG\nCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE4MDIwMTAx\nMTExNFowIwYJKoZIhvcNAQkEMRYEFNKi/xYPqnN6zp/RogVZBZ3ICGOBMFIGCSqG\nSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3\nDQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMA0GCSqGSIb3DQEBAQUABIIB\nAJQtrcrRd/3PLS9rhey0RyU1ZRnuB4Ib+y/wAan3k+fRNpA70F9kaxxcme78eqho\nHH5rvizY4InvrG1wjtpYeickMHp+s0E51j1AbVxOgZ/UiEgjLRq9Dv5OCPgKoLaB\nlsyCj41baXvlqzXZ8RaP7Li2SPLpdksqLE5yegiN+yMIiEPfNAtmaRLN3CNnbbMf\nX1bF4ifgyhy3P1VGPPk+WTiQyu0VqySrlhz0Ux9+acB/TFUrymFEKxJ/7bM//4nL\nUpEQVlnj9rl3OYzhYgDsQgz0kGU+6UG7Iw6gB9xFAMeE/1Y5Xrs2UdjBVC9hkSy8\nr1+2rPF1yixiWjiORNk4kyU=\n-----END PKCS7-----\n\nRegards,\nCory\n\nOn Fri, Jan 12, 2018 at 5:14 AM, nullius via bitcoin-dev\n\u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e On 2018-01-12 at 08:54:12 +0000, Peter Todd \u003cpete at petertodd.org\u003e wrote:\n\u003e\u003e\n\u003e\u003e While a clunky way to do it, you can use the `-signer` option to tell\n\u003e\u003e OpenSSL to write the signer's certificate to a file. That certificate can\n\u003e\u003e then be compared to the one from the repo, which was still in the repo as of\n\u003e\u003e the (signed!) v0.15.1 tag.\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e Fun fact: OpenTimestamps has git integration, which means you can extract\n\u003e\u003e a OTS proof from 2016 for that certificate from the repo:\n\u003e\u003e\n\u003e\u003e $ git checkout v0.15.1\n\u003e\u003e $ ots git-extract share/certs/BitcoinFoundation_Apple_Cert.pem\n\u003e\u003e share/certs/BitcoinFoundation_Apple_Cert.pem.ots\n\u003e\u003e 36f60a5d5b1bc9a12b87d6475e3245b8236775e4\n\u003e\u003e $ ots verify share/certs/BitcoinFoundation_Apple_Cert.pem.ots\n\u003e\u003e Assuming target filename is\n\u003e\u003e 'share/certs/BitcoinFoundation_Apple_Cert.pem'\n\u003e\u003e Success! Bitcoin attests data existed as of Thu Oct 13 14:08:59 2016\n\u003e\u003e EDT\n\u003e\u003e\n\u003e\u003e Homework problem: write a paragraph explaining how the proof generated by\n\u003e\u003e the above three commands are crypto snakeoil that proved little. :)\n\u003e\n\u003e\n\u003e It says, “Bitcoin attests data existed”. Within the scope of those three\n\u003e commands, I don’t see any proof of who put it there. Does OTS check the PGP\n\u003e signatures on *commits* when it does that `git-extract`? The signature on\n\u003e the v0.15.1 tag is irrelevant to that question; and FWIW, I don’t see *that*\n\u003e signature being verified here, either.\n\u003e Second paragraph: Moreover, with the breaking of SHA-1, it *may* be\n\u003e feasible for some scenario to play out involving two different PEMs with the\n\u003e same hash, but different public keys (and thus different corresponding\n\u003e private keys). I don’t know off the top of my head if somewhere could be\n\u003e found to stash the magic bits; and the overall scenario would need to be a\n\u003e bit convoluted. I think a malicious committer who lacked access to the\n\u003e signing key *may* be able to create a collision between the real\n\u003e certificate, and a certificate as for which he has the private key—then\n\u003e switch them, later. Maybe. I would not discount the possibility off-hand.\n\u003e OTS would prove nothing, if he had the foresight to obtain timestamps\n\u003e proving that both certificates existed at the appropriate time (which they\n\u003e would need to anyway; it is not a post facto preimage attack).\n\u003e\n\u003e\u003e [...]\n\u003e\u003e\n\u003e\u003e What's nice about OpenPGP's \"clearsigned\" format is how it ignores\n\u003e\u003e whitespace; a replica of that might be a nice thing for OTS to be able to do\n\u003e\u003e too. Though that's on low priority, as there's some tricky design choices(1)\n\u003e\u003e to be made about how to nicely nest clearsigned PGP within OTS.\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e 1) For example, I recently found a security hole related to clearsigned\n\u003e\u003e PGP recently. Basically the issue was that gpg --verify will return true on\n\u003e\u003e a file that looks like the following:\n\u003e\u003e\n\u003e\u003e 1d7a363ce12430881ec56c9cf1409c49c491043618e598c356e2959040872f5a\n\u003e\u003e foo-v2.0.tar.gz\n\u003e\u003e -----BEGIN PGP SIGNED MESSAGE-----\n\u003e\u003e Hash: SHA256\n\u003e\u003e\n\u003e\u003e e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855\n\u003e\u003e foo-v1.0.tar.gz\n\u003e\u003e -----BEGIN PGP SIGNATURE-----\n\u003e\u003e\n\u003e\u003e \u003csnip pgp stuff\u003e\n\u003e\u003e -----END PGP SIGNATURE-----\n\u003e\u003e\n\u003e\u003e The system I was auditing then did something like this to verify that the\n\u003e\u003e file was signed:\n\u003e\u003e\n\u003e\u003e set -e # exit immediately on error\n\u003e\u003e gpg --verify SHA256SUMS.asc\n\u003e\u003e cat SHA256SUMS.asc | grep foo-v2.0.tar.gz\n\u003e\u003e \u003cdo installation\u003e\n\u003e\u003e\n\u003e\u003e While it makes it a bit less user friendly, the fact that PKCS7's encoding\n\u003e\u003e made it impossible to see the message you signed until it's been properly\n\u003e\u003e verified is a good thing re: security.\n\u003e\n\u003e\n\u003e Potential solutions using PGP:\n\u003e\n\u003e 0. Don’t use clearsigning.\n\u003e\n\u003e 1. Use a detached signature.\n\u003e\n\u003e 2. Use `gpg --verify -o -` and pipe that to `grep`, rather than illogically\n\u003e separating verification from use of data. (By the way, where is the *hash*\n\u003e verified? Was `grep` piped to `sha256sum -c`?)\n\u003e\n\u003e 3. Have shell scripts written by somebody who knows how to think about\n\u003e security, and/or who knows how to RTFM; quoting gpg(1):\n\u003e\n\u003e\u003e Note: When verifying a cleartext signature, gpg verifies only what makes\n\u003e\u003e up the cleartext signed data and not any extra data outside of the cleartext\n\u003e\u003e signature or the header lines directly following the dash marker line. The\n\u003e\u003e option --output may be used to write out the actual signed data, but there\n\u003e\u003e are other pitfalls with this format as well. It is suggested to avoid\n\u003e\u003e cleartext signatures in favor of detached signatures.\n\u003e\n\u003e\n\u003e 4. Obtain an audit from Peter Todd.\n\u003e\n\u003e\u003e And yes, I checked: Bitcoin Core's contrib/verifybinaries/verify.sh isn't\n\u003e\u003e vulnerable to this mistake. :)\n\u003e\n\u003e\n\u003e P.S., oh my! *Unsigned data:*\n\u003e\n\u003e\u003e _______________________________________________\n\u003e\u003e bitcoin-dev mailing list\n\u003e\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\n\u003e\n\u003e --\n\u003e nullius at nym.zone | PGP ECC: 0xC2E91CD74A4C57A105F6C21B5A00591B2F307E0C\n\u003e Bitcoin: bc1qcash96s5jqppzsp8hy8swkggf7f6agex98an7h | (Segwit nested:\n\u003e 3NULL3ZCUXr7RDLxXeLPDMZDZYxuaYkCnG) (PGP RSA: 0x36EBB4AB699A10EE)\n\u003e “‘If you’re not doing anything wrong, you have nothing to hide.’\n\u003e No! Because I do nothing wrong, I have nothing to show.” — nullius\n\u003e\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e",
"sig": "84d1485c17388ac5c72f405bf747241c6da695d101ccac6c9c0cc0072849466305a0090010ee695150c7829f86b2cde03924660052bbfb74887b2750cd353e04"
}