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
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <brian.erdelyi@gmail.com>) id 1YHtxj-0003nb-9s
for bitcoin-development@lists.sourceforge.net;
Sun, 01 Feb 2015 12:49:15 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.192.45 as permitted sender)
client-ip=209.85.192.45; envelope-from=brian.erdelyi@gmail.com;
helo=mail-qg0-f45.google.com;
Received: from mail-qg0-f45.google.com ([209.85.192.45])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1YHtxh-000149-J4
for bitcoin-development@lists.sourceforge.net;
Sun, 01 Feb 2015 12:49:15 +0000
Received: by mail-qg0-f45.google.com with SMTP id q107so44152053qgd.4
for <bitcoin-development@lists.sourceforge.net>;
Sun, 01 Feb 2015 04:49:08 -0800 (PST)
X-Received: by 10.229.174.70 with SMTP id s6mr31330482qcz.7.1422794948175;
Sun, 01 Feb 2015 04:49:08 -0800 (PST)
Received: from [192.168.1.58] ([64.147.83.112])
by mx.google.com with ESMTPSA id 78sm15383899qgi.38.2015.02.01.04.49.06
(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
Sun, 01 Feb 2015 04:49:07 -0800 (PST)
Content-Type: multipart/alternative;
boundary="Apple-Mail=_9DC5231B-226F-4B81-9007-F1D7B91A1D6C"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\))
From: Brian Erdelyi <brian.erdelyi@gmail.com>
In-Reply-To: <CAAt2M1-b7ByF0yVSmwD_nj3uUSo5GFOmH860n1k6oKX_sqvEkw@mail.gmail.com>
Date: Sun, 1 Feb 2015 08:49:05 -0400
Message-Id: <88211D58-DE9D-4B4A-B3A5-2EEFDFC5E02B@gmail.com>
References: <27395C55-CF59-4E65-83CA-73F903272C5F@gmail.com>
<CAAt2M18kRgJeNGu9GeKabRpTKPX9rVeoYiKoanz99bmV2jaf4w@mail.gmail.com>
<1348028F-26F8-42CB-9859-C9CB751BF0C9@gmail.com>
<CAAt2M1_3BdKQTVxsN7Hc-W=q0_NWyhBg1UAuSwxRQ8BePDa-8g@mail.gmail.com>
<CAAt2M1-b7ByF0yVSmwD_nj3uUSo5GFOmH860n1k6oKX_sqvEkw@mail.gmail.com>
To: Natanael <natanael.l@gmail.com>
X-Mailer: Apple Mail (2.2070.6)
X-Spam-Score: -0.6 (/)
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
(brian.erdelyi[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
1.0 HTML_MESSAGE BODY: HTML included in message
-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
author's domain
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: 1YHtxh-000149-J4
Cc: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] Proposal to address Bitcoin malware
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: Sun, 01 Feb 2015 12:49:15 -0000
--Apple-Mail=_9DC5231B-226F-4B81-9007-F1D7B91A1D6C
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=utf-8
In online banking, the banks generate account numbers. An attacker =
cannot generate their own account number and the likelihood of an =
attacker having the same account number that I am trying to transfer =
funds to is low and this is why OCRA is effective with online banking.
With Bitcoin, the Bitcoin address is comparable to the recipient=E2=80=99s=
bank account number. I now see how an an attacker can brute force the =
bitcoin address with vanitygen. Is there any way to generate an 8 digit =
number from the bitcoin address that can be used to verify transactions =
in such a way (possibly with hashing?) that brute forcing a bitcoin =
address would take longer than a reasonable period of time (say 60 =
seconds) so a system could time out if a transaction was not completed =
in that time?
I=E2=80=99ve also looked into BIP70 (Payment Protocol) that claims =
protection against man-in-the-middle/man-in-the-browser (MitB) based =
attacks. A common way to protect against this is with out-of-band =
transaction verification =
(http://en.wikipedia.org/wiki/Man-in-the-browser#Out-of-band_transaction_v=
erification =
<http://en.wikipedia.org/wiki/Man-in-the-browser#Out-of-band_transaction_v=
erification>). I see how BIP 70 verifies the payment request, however, =
is there any way to verify that the transaction signed by the wallet =
matches the request before it is sent to the blockchain (and how can =
this support out of band verification)? Perhaps this is something that =
can only be supported when sending money with web based wallets.
Brian Erdelyi=
--Apple-Mail=_9DC5231B-226F-4B81-9007-F1D7B91A1D6C
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
charset=utf-8
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html =
charset=3Dutf-8"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" =
class=3D""><div class=3D""><br class=3D""></div><div class=3D"">In =
online banking, the banks generate account numbers. An attacker =
cannot generate their own account number and the likelihood of an =
attacker having the same account number that I am trying to transfer =
funds to is low and this is why OCRA is effective with online =
banking.</div><div class=3D""><br class=3D""></div><div class=3D"">With =
Bitcoin, the Bitcoin address is comparable to the recipient=E2=80=99s =
bank account number. I now see how an an attacker can brute force =
the bitcoin address with vanitygen. Is there any way to generate =
an 8 digit number from the bitcoin address that can be used to verify =
transactions in such a way (possibly with hashing?) that brute forcing a =
bitcoin address would take longer than a reasonable period of time (say =
60 seconds) so a system could time out if a transaction was not =
completed in that time?</div><div class=3D""><br class=3D""></div><div =
class=3D"">I=E2=80=99ve also looked into BIP70 (Payment Protocol) that =
claims protection against man-in-the-middle/man-in-the-browser (MitB) =
based attacks. A common way to protect against this is with =
out-of-band transaction verification (<a =
href=3D"http://en.wikipedia.org/wiki/Man-in-the-browser#Out-of-band_transa=
ction_verification" =
class=3D"">http://en.wikipedia.org/wiki/Man-in-the-browser#Out-of-band_tra=
nsaction_verification</a>). I see how BIP 70 verifies the payment =
request, however, is there any way to verify that the transaction signed =
by the wallet matches the request before it is sent to the blockchain =
(and how can this support out of band verification)? Perhaps this =
is something that can only be supported when sending money with web =
based wallets.</div><div class=3D""><br class=3D""></div><div =
class=3D"">Brian Erdelyi</div></body></html>=
--Apple-Mail=_9DC5231B-226F-4B81-9007-F1D7B91A1D6C--
|
