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
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <adam.back@gmail.com>) id 1UZfkO-0004up-JC
for bitcoin-development@lists.sourceforge.net;
Tue, 07 May 2013 11:07:52 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
designates 74.125.83.44 as permitted sender)
client-ip=74.125.83.44; envelope-from=adam.back@gmail.com;
helo=mail-ee0-f44.google.com;
Received: from mail-ee0-f44.google.com ([74.125.83.44])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1UZfkN-0007wb-Ab
for bitcoin-development@lists.sourceforge.net;
Tue, 07 May 2013 11:07:52 +0000
Received: by mail-ee0-f44.google.com with SMTP id t10so241571eei.3
for <bitcoin-development@lists.sourceforge.net>;
Tue, 07 May 2013 04:07:45 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=google.com; s=20120113;
h=x-received:date:from:to:cc:subject:message-id:references
:mime-version:content-type:content-disposition:in-reply-to
:user-agent:x-hashcash:x-hashcash:x-hashcash:x-hashcash;
bh=xME/4lTz+NoxxjOGXAs07r8Wm7HJ+nt8VeY16yLjTCM=;
b=iWyxIUMF/hM4sZclHHeF58tu1BG9ZPVJZesMAL9pRHEuF6ygOd4ZdNACRas+mMIf66
1FTvPiBjMJMjGyFZp+LhXSCc5vDcNFPi3V1i5m95btfXRxLIRneov6/aXzI9JYx3mvWy
LODR3HmYxG+wWJ4EJKXFq7GSOr6zhPeSKcZBACVcIX9/nJ1VaJwLXHAAJ83YCIt+5Her
BDm9U5c3frz+nfRRP7SI6+cRAxt215kjVfTYmUm/yOwX/gppuFEaThJpEknp3hC7gFEZ
BQzY2kttZmzLOd9N7D88DMASwQZ6DJA6x1/uDAAJ4hMNmuZQmCzVH9tpZnhyCEVzw8QM
VpCg==
X-Received: by 10.14.172.197 with SMTP id t45mr4219854eel.37.1367924864893;
Tue, 07 May 2013 04:07:44 -0700 (PDT)
Received: from netbook (c83-90.i07-21.onvol.net. [92.251.83.90])
by mx.google.com with ESMTPSA id
bp51sm36710313eeb.5.2013.05.07.04.07.43 for <multiple recipients>
(version=TLSv1.1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
Tue, 07 May 2013 04:07:44 -0700 (PDT)
Received: by netbook (Postfix, from userid 1000)
id C30D12E0619; Tue, 7 May 2013 13:07:41 +0200 (CEST)
Received: by flare (hashcash-sendmail, from uid 1000);
Tue, 7 May 2013 13:07:40 +0200
Date: Tue, 7 May 2013 13:07:40 +0200
From: Adam Back <adam@cypherspace.org>
To: Mike Hearn <mike@plan99.net>
Message-ID: <20130507110740.GA10449@netbook.cypherspace.org>
References: <CANEZrP1YFCLmasOrdxdKDP1=x8nKuy06kGRqZwpnmnhe3-AroA@mail.gmail.com>
<20130506161216.GA5193@petertodd.org>
<CA+8xBpfdY7GsQiyrHuOG-MqXon0RGShpg2Yv-KeAXQ-503kAsA@mail.gmail.com>
<20130506163732.GB5193@petertodd.org>
<CANEZrP2WqXZVRJp6ag=RC4mSkt+a6qTYYpvE=DW_0Rdr=_BBHA@mail.gmail.com>
<20130506180418.GA3797@netbook.cypherspace.org>
<CAAS2fgSh+dYxSak8HvE0Sr4=zxzRc=3dMQ6X_nD_a+OdacUBZQ@mail.gmail.com>
<20130506225146.GA6657@netbook.cypherspace.org>
<CAAS2fgQU5yHFEUfzVwco=L2YKU=Ci0Od+4w59o1wx5UUf1w3VQ@mail.gmail.com>
<CANEZrP1unq_36p0_VJ6CnHof2Sxb4B8go3BK6tPzEMbSLQBBtg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Disposition: inline
In-Reply-To: <CANEZrP1unq_36p0_VJ6CnHof2Sxb4B8go3BK6tPzEMbSLQBBtg@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Hashcash: 1:20:130507:mike@plan99.net::KVZv1xB65avanZ59:002f34
X-Hashcash: 1:20:130507:gmaxwell@gmail.com::yeke8Q8S3O4Z1l1y:0000000000000000000
0000000000000000000000001AXv
X-Hashcash: 1:20:130507:bitcoin-development@lists.sourceforge.net::k9Lzj1CaoAMP+
zLb:000000000000000000001fEv
X-Hashcash: 1:20:130507:adam@cypherspace.org::hn+wbq+aQaSaONqa:00000000000000000
0000000000000000000000000dwt
X-Spam-Score: -1.5 (-)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
sender-domain
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(adam.back[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
0.0 T_FILL_THIS_FORM_SHORT Fill in a short form with personal
information
X-Headers-End: 1UZfkN-0007wb-Ab
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] limits of network hacking/netsplits (was:
Discovery/addr packets)
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Tue, 07 May 2013 11:07:52 -0000
Well its a bit more hopeful than that :)
On Tue, May 07, 2013 at 11:17:17AM +0200, Mike Hearn wrote:
>> Seems like the website redesign managed to hide the signatures pretty
>> good.
>
>Security theater indeed - even if people check the signatures, where
>did they get the identities of the signers/developers from? Oh right,
>the same website that served them the binary.
If they are PGP signatures, they can check the PGP WoT; its not that
hopeless some us eg have our keys in Ross Anderson's PGP Global Trust
Register, a PGP and CA key fingerprint book.
http://www.cl.cam.ac.uk/research/security/Trust-Register/index.html
Probably most of the CA keys expired, but many of the PGP keys didnt. So to
the extent that those people take PGP WoT seriously, and the main developers
names and email addresses are known and scattered around hundreds of web
mailing list archives etc there is some trust anchor.
And even without a PGP WoT connection, if the website had SSL enabled, they
can trust the binaries its sending to the extent that it is securely
maintained, and to the limit of the CA security weakest link (modulo sub-CA
malfeasance, and all the certification domain ownership laxness you or
someone mentioned in another mail). That there are limitations in it doesnt
mean you should not avail of the (moderately crummy) state of the art!
And that is tied back to the domain itself hwich is very mnemonic and
referenced widely in print, tv, websites etc.
>3) I never got around to trying it, but the threshold RSA library I
>obtained is theoretically capable of splitting the RSA keys used to
>protect updates. I've talked to Andreas about this a little bit, and I
>think he's open to the idea of splitting the Android signing key so it
>requires a quorum of developers to release an update. This is Shoup
>threshold RSA, not a Shamir secret share of the key bits.
I guess its the least of the concerns but I believe Damgards is better.
Another possibility is threshold DSA (which is built using Damgards Paillier
additively homomorphic cryptosystem extension) and discrete log schemes are
easier to setup with zero-trust. Other simpler discrete log signatures ie
Schnorr are much easier to work with (threshold DSA is a mite complicated),
but NIST tweaked Schnorr to create DSA, and the rest is history. The trust
n-1 of n is good enough for signatures because anyway that is above the
assurance of the signature.
>On Linux we're actually the most exposed. It has by far the worst
>situation of all - a culture in which man-in-the-middle attacks by
>package maintainers are not only common but actively encouraged. The
>Debian OpenSSL fiasco showed the critical danger this can place people
>in. I believe we should have a health warning on the website telling
>people to only get binaries from us unless they are on a distribution
>that we are verifying doesn't apply any patches. But that's a ton of
>work and I long ago burned out on the politics of Linux software
>distribution.
Well before I tried the download I had downloaded and compiled a few
versions from git. But to get a stable and experience the non-programmer
view I did first try "yum install bitcoin" and then "yum whatprovides bitcoin"
on fedora 18 with +rpmfusion and there appeared to be no package!
I didnt find the signature on the source either or I would've checked.
Other ways you could get usefully get assurance of the source is multiple
people signing the release, with an asserted meaning being - I checked the
patches that went into this and I see nothing malicious. It might help if
one or more of the signer were pseudonymous even (eg Satoshi if willing)
because you cant coerce legally, nor physically a pseudonymous person
because you cant find them. Its a lot of pressure on open secure coding
process when there is $1bil value protected by the integrity of the code.
(It seems the most likely avenue to bypass that maybe simply the attacker to
just become a committer and slip the 0-day past the review process. There
were in the past modest-impact and plausible looking mistakes in PGP
discovered after sometime.)
Adam
|
