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
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <mh.in.england@gmail.com>) id 1UVNCn-0008BK-RL
for bitcoin-development@lists.sourceforge.net;
Thu, 25 Apr 2013 14:31:25 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.219.46 as permitted sender)
client-ip=209.85.219.46; envelope-from=mh.in.england@gmail.com;
helo=mail-oa0-f46.google.com;
Received: from mail-oa0-f46.google.com ([209.85.219.46])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1UVNCk-0004d7-2Y
for bitcoin-development@lists.sourceforge.net;
Thu, 25 Apr 2013 14:31:25 +0000
Received: by mail-oa0-f46.google.com with SMTP id k3so2875893oag.5
for <bitcoin-development@lists.sourceforge.net>;
Thu, 25 Apr 2013 07:31:16 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.182.97.168 with SMTP id eb8mr16111229obb.89.1366900276683;
Thu, 25 Apr 2013 07:31:16 -0700 (PDT)
Sender: mh.in.england@gmail.com
Received: by 10.76.167.169 with HTTP; Thu, 25 Apr 2013 07:31:16 -0700 (PDT)
In-Reply-To: <FDF215AE-F9A4-4EE3-BDC9-0A4EF027423A@swipeclock.com>
References: <mailman.38128.1366844895.4905.bitcoin-development@lists.sourceforge.net>
<20130425095855.GA30535@crunch>
<CANEZrP3EhS3-HnPT_exc9MjZn-ywZggSzqSHPzHU5J2EZuLQtg@mail.gmail.com>
<20130425102853.GA31573@crunch>
<CANEZrP1343gX-utnbO16Z6axMDMmvYpiGXW8_Vc-yec03ip=1g@mail.gmail.com>
<FDF215AE-F9A4-4EE3-BDC9-0A4EF027423A@swipeclock.com>
Date: Thu, 25 Apr 2013 16:31:16 +0200
X-Google-Sender-Auth: wrwYOXmrHsJrQjZmkDfMvWANFNk
Message-ID: <CANEZrP0FS5CZaqEEwCZM-nfPB9D2TfC_moX3BE+TEnfWtc=aOg@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Mike Caldwell <mcaldwell@swipeclock.com>
Content-Type: multipart/alternative; boundary=047d7b2e41e66f6aea04db304552
X-Spam-Score: -0.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
(mh.in.england[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
1.0 HTML_MESSAGE BODY: HTML included in message
0.1 DKIM_SIGNED Message has a DKIM or DK signature,
not necessarily valid
-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
X-Headers-End: 1UVNCk-0004d7-2Y
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>,
"timo.hanke@web.de" <timo.hanke@web.de>
Subject: Re: [Bitcoin-development] Cold Signing Payment Requests
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: Thu, 25 Apr 2013 14:31:26 -0000
--047d7b2e41e66f6aea04db304552
Content-Type: text/plain; charset=UTF-8
On Thu, Apr 25, 2013 at 4:13 PM, Mike Caldwell <mcaldwell@swipeclock.com>wrote:
> I am not sure if my replies hit the list. If not, can anyone who sees this
> help?
>
> In the past, I have pre signed (with PGP) large batches of Bitcoin
> addresses for distribution on my server. This way, even in the event of
> compromise, there is no way someone could substitute an address of their
> own and have it have the same characteristics as other addresses I have
> signed. The same general concept could be used to keep signing keys off
> the web server.
>
> Mike
>
I didn't see your other replies but got this one.
The assumption you made by doing that is that people can obtain your PGP
key. This leads to the question of how someone knows what your key is or
that you signed the list in the first place. The most obvious way is to go
to https://www.casascius.com/ and click "My PGP key" -> but we already
failed at this point if your web server was hacked. I'd have to learn about
your cryptographic identity via some other secure channel, but usually that
doesn't exist.
Being able to survive web server hacks is intuitively attractive because
web servers tend to be so insecure. But unfortunately there doesn't seem to
be any good way to do this with todays infrastructure because for most
businesses, their website *is* their identity, and if a hacker controls
that they it's very hard for anyone (including CAs) to know that something
has gone wrong.
I think there are some simple mitigations we can use in the short term.
One is that wallets could count how many times you paid to addresses signed
by a particular cert. If you're a repeat customer and your wallet says "You
have never paid this recipient before" instead of "You have paid this
recipient 4 times" then you might be suspicious. Someone pointed out to me
that the current payment protocol has nothing to say on phishing using
confusible domains - this could help with that too, and it's easy to
implement. Of course it means you get reset whenever your certificate
expires and has to be renewed, and crying wolf is often worse than doing
nothing at all. So that's an issue.
With time there might be more complex solutions available, like extensions
to X.509/CA infrastructure (if bitcoin stays growing and popular). Also,
alternative PKIs like DNSSEC or the ePassport PKI might be useful. In your
case Mike you aren't really a company, you're trading under your own name,
so signing the key list under your legal identity is really the best
solution. It's just not easily available right now.
--047d7b2e41e66f6aea04db304552
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra">On Thu, Apr 25, 2013 at 4:13 PM=
, Mike Caldwell <span dir=3D"ltr"><<a href=3D"mailto:mcaldwell@swipecloc=
k.com" target=3D"_blank">mcaldwell@swipeclock.com</a>></span> wrote:<br>=
<div class=3D"gmail_quote">
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex"><div dir=3D"auto"><div>I am not sure if my replies hit the=
list. If not, can anyone who sees this help?</div>
<div><br></div><div>In the past, I have pre signed (with PGP) large batches=
of Bitcoin addresses for distribution on my server. This way, even in the =
event of compromise, there is no way someone could substitute an address of=
their own and have it have the same characteristics as other addresses I h=
ave signed. =C2=A0The same general concept could be used to keep signing ke=
ys off the web server.=C2=A0<br>
<br><div>Mike</div></div></div></blockquote><div><br></div><div>I didn'=
t see your other replies but got this one.<div><br></div><div>The assumptio=
n you made by doing that is that people can obtain your PGP key. This leads=
to the question of how someone knows what your key is or that you signed t=
he list in the first place. The most obvious way is to go to=C2=A0<a href=
=3D"https://www.casascius.com/">https://www.casascius.com/</a>=C2=A0and cli=
ck "My PGP key" -> but we already failed at this point if your=
web server was hacked. I'd have to learn about your cryptographic iden=
tity via some other secure channel, but usually that doesn't exist.</di=
v>
</div><div><br></div><div style>Being able to survive web server hacks is i=
ntuitively attractive because web servers tend to be so insecure. But unfor=
tunately there doesn't seem to be any good way to do this with todays i=
nfrastructure because for most businesses, their website <b>is</b>=C2=A0the=
ir identity, and if a hacker controls that they it's very hard for anyo=
ne (including CAs) to know that something has gone wrong.<br>
</div><div style><br></div><div style>I think there are some simple mitigat=
ions we can use in the short term.</div><div style><br></div><div style>One=
is that wallets could count how many times you paid to addresses signed by=
a particular cert. If you're a repeat customer and your wallet says &q=
uot;You have never paid this recipient before" instead of "You ha=
ve paid this recipient 4 times" then you might be suspicious. Someone =
pointed out to me that the current payment protocol has nothing to say on p=
hishing using confusible domains - this could help with that too, and it=
9;s easy to implement. Of course it means you get reset whenever your certi=
ficate expires and has to be renewed, and crying wolf is often worse than d=
oing nothing at all. So that's an issue.</div>
<div style><br></div><div style>With time there might be more complex solut=
ions available, like extensions to X.509/CA infrastructure (if bitcoin stay=
s growing and popular). Also, alternative PKIs like DNSSEC or the ePassport=
PKI might be useful. In your case Mike you aren't really a company, yo=
u're trading under your own name, so signing the key list under your le=
gal identity is really the best solution. It's just not easily availabl=
e right now.</div>
</div></div></div>
--047d7b2e41e66f6aea04db304552--
|
