MIME-Version: 1.0
Reply-To: lists@coryfields.com
In-Reply-To: <23bf1f30b85d0f23d6c9eab93f1d8e06@nym.zone>
References: <CAApLimjGy6TCd7kg8RKkuGqAZTfcuNSfsrDowEsEcbEnM_0rzg@mail.gmail.com>
	<20180112085412.GA8088@savin.petertodd.org>
	<23bf1f30b85d0f23d6c9eab93f1d8e06@nym.zone>
From: Cory Fields <lists@coryfields.com>
Date: Wed, 31 Jan 2018 20:14:45 -0500
Message-ID: <CAApLimi48s9i6U8M1EYOpO5yapQ8ry3zn9sXF1Sx6bhLq0FYmg@mail.gmail.com>
To: nullius <nullius@nym.zone>, 
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Subject: Re: [bitcoin-dev] New Bitcoin Core macOS signing key
Precedence: list

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=3D
-----END PKCS7-----

Regards,
Cory

On Fri, Jan 12, 2018 at 5:14 AM, nullius via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> 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 ca=
n
>> then be compared to the one from the repo, which was still in the repo a=
s of
>> the (signed!) v0.15.1 tag.
>>
>>
>> Fun fact: OpenTimestamps has git integration, which means you can extrac=
t
>> 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 b=
y
>> the above three commands are crypto snakeoil that proved little. :)
>
>
> It says, =E2=80=9CBitcoin attests data existed=E2=80=9D.  Within the scop=
e of those three
> commands, I don=E2=80=99t see any proof of who put it there.  Does OTS ch=
eck the PGP
> signatures on *commits* when it does that `git-extract`?  The signature o=
n
> the v0.15.1 tag is irrelevant to that question; and FWIW, I don=E2=80=99t=
 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=E2=80=99t 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=E2=80=
=94then
> switch them, later.  Maybe.  I would not discount the possibility off-han=
d.
> OTS would prove nothing, if he had the foresight to obtain timestamps
> proving that both certificates existed at the appropriate time (which the=
y
> 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 t=
o do
>> too. Though that's on low priority, as there's some tricky design choice=
s(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 th=
e
>> 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 encodi=
ng
>> made it impossible to see the message you signed until it's been properl=
y
>> verified is a good thing re: security.
>
>
> Potential solutions using PGP:
>
> 0. Don=E2=80=99t use clearsigning.
>
> 1. Use a detached signature.
>
> 2. Use `gpg --verify -o -` and pipe that to `grep`, rather than illogical=
ly
> separating verification from use of data.  (By the way, where is the *has=
h*
> 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  make=
s
>> up the cleartext signed data and not any extra data outside of the clear=
text
>> 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 the=
re
>> 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)
> =E2=80=9C=E2=80=98If you=E2=80=99re not doing anything wrong, you have no=
thing to hide.=E2=80=99
> No!  Because I do nothing wrong, I have nothing to show.=E2=80=9D =E2=80=
=94 nullius
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>