1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
|
Return-Path: <nullius@nym.zone>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 22D24EBF
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 12 Jan 2018 10:15:06 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from mx2.mailbox.org (mx2.mailbox.org [80.241.60.215])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 2E958D0
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 12 Jan 2018 10:15:03 +0000 (UTC)
Received: from smtp2.mailbox.org (smtp2.mailbox.org [80.241.60.241])
(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
(No client certificate requested)
by mx2.mailbox.org (Postfix) with ESMTPS id 118924117F;
Fri, 12 Jan 2018 11:15:00 +0100 (CET)
X-Virus-Scanned: amavisd-new at heinlein-support.de
Received: from smtp2.mailbox.org ([80.241.60.241])
by spamfilter02.heinlein-hosting.de (spamfilter02.heinlein-hosting.de
[80.241.56.116]) (amavisd-new, port 10030)
with ESMTP id b0ApjvlmBZYK; Fri, 12 Jan 2018 11:14:55 +0100 (CET)
Date: Fri, 12 Jan 2018 10:14:11 +0000
From: nullius <nullius@nym.zone>
To: Peter Todd <pete@petertodd.org>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Message-ID: <23bf1f30b85d0f23d6c9eab93f1d8e06@nym.zone>
References: <CAApLimjGy6TCd7kg8RKkuGqAZTfcuNSfsrDowEsEcbEnM_0rzg@mail.gmail.com>
<20180112085412.GA8088@savin.petertodd.org>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
protocol="application/pgp-signature"; boundary="bqrva4rmndb23fn6"
Content-Disposition: inline
In-Reply-To: <20180112085412.GA8088@savin.petertodd.org>
X-Spam-Status: No, score=-0.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW,
URIBL_BLACK autolearn=no version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
X-Mailman-Approved-At: Fri, 12 Jan 2018 10:33:06 +0000
Subject: Re: [bitcoin-dev] New Bitcoin Core macOS signing key
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Fri, 12 Jan 2018 10:15:06 -0000
--bqrva4rmndb23fn6
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
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=20
>OpenSSL to write the signer's certificate to a file. That certificate=20
>can then be compared to the one from the repo, which was still in the=20
>repo as of the (signed!) v0.15.1 tag.
>
>
>Fun fact: OpenTimestamps has git integration, which means you can=20
>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/c=
erts/BitcoinFoundation_Apple_Cert.pem.ots 36f60a5d5b1bc9a12b87d6475e3245b82=
36775e4
> $ 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 E=
DT
>
>Homework problem: write a paragraph explaining how the proof generated=20
>by the above three commands are crypto snakeoil that proved little. :)
It says, =E2=80=9CBitcoin attests data existed=E2=80=9D. Within the scope =
of those=20
three commands, I don=E2=80=99t see any proof of who put it there. Does OT=
S=20
check the PGP signatures on *commits* when it does that `git-extract`? =20
The signature on the v0.15.1 tag is irrelevant to that question; and=20
FWIW, I don=E2=80=99t see *that* signature being verified here, either. =20
Second paragraph: Moreover, with the breaking of SHA-1, it *may* be=20
feasible for some scenario to play out involving two different PEMs with=20
the same hash, but different public keys (and thus different=20
corresponding private keys). I don=E2=80=99t know off the top of my head i=
f=20
somewhere could be found to stash the magic bits; and the overall=20
scenario would need to be a bit convoluted. I think a malicious=20
committer who lacked access to the signing key *may* be able to create a=20
collision between the real certificate, and a certificate as for which=20
he has the private key=E2=80=94then switch them, later. Maybe. I would no=
t=20
discount the possibility off-hand. OTS would prove nothing, if he had=20
the foresight to obtain timestamps proving that both certificates=20
existed at the appropriate time (which they would need to anyway; it is=20
not a post facto preimage attack).
>[...]
>
>What's nice about OpenPGP's "clearsigned" format is how it ignores=20
>whitespace; a replica of that might be a nice thing for OTS to be able=20
>to do too. Though that's on low priority, as there's some tricky design=20
>choices(1) to be made about how to nicely nest clearsigned PGP within=20
>OTS.
>
>
>1) For example, I recently found a security hole related to clearsigned=20
>PGP recently. Basically the issue was that gpg --verify will return=20
>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=20
>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=20
>encoding made it impossible to see the message you signed until it's=20
>been properly 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=20
illogically separating verification from use of data. (By the way,=20
where is the *hash* verified? Was `grep` piped to `sha256sum -c`?)
3. Have shell scripts written by somebody who knows how to think about=20
security, and/or who knows how to RTFM; quoting gpg(1):
>Note: When verifying a cleartext signature, gpg verifies only what =20
>makes up the cleartext signed data and not any extra data outside of=20
>the cleartext signature or the header lines directly following the dash=20
>marker line. The option --output may be used to write out the actual=20
>signed data, but there are other pitfalls with this format as well. It=20
>is suggested to avoid cleartext signatures in favor of detached=20
>signatures.
4. Obtain an audit from Peter Todd.
>And yes, I checked: Bitcoin Core's contrib/verifybinaries/verify.sh=20
>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
--=20
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 noth=
ing to hide.=E2=80=99
No! Because I do nothing wrong, I have nothing to show.=E2=80=9D =E2=80=94=
nullius
--bqrva4rmndb23fn6
Content-Type: application/pgp-signature; name="signature.asc"
-----BEGIN PGP SIGNATURE-----
iHUEARYKAB0WIQSNOMR84IlYpr/EF5vEJ5MVn575SQUCWliKcQAKCRDEJ5MVn575
Se0DAQCr+vGN5jC46zJKOFdLkJZ/yasU1HF3wobwmn+alTwjhQEA7n8OFP+D0FYt
7MtOm6SG0SOVICGZIz9ISBTArdR1kQ8=
=hrgm
-----END PGP SIGNATURE-----
--bqrva4rmndb23fn6--
|
