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
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <natanael.l@gmail.com>) id 1YHhbz-0001ps-00
for bitcoin-development@lists.sourceforge.net;
Sat, 31 Jan 2015 23:37:59 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
designates 74.125.82.46 as permitted sender)
client-ip=74.125.82.46; envelope-from=natanael.l@gmail.com;
helo=mail-wg0-f46.google.com;
Received: from mail-wg0-f46.google.com ([74.125.82.46])
by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1YHhby-0001bO-1O
for bitcoin-development@lists.sourceforge.net;
Sat, 31 Jan 2015 23:37:58 +0000
Received: by mail-wg0-f46.google.com with SMTP id l2so32754470wgh.5
for <bitcoin-development@lists.sourceforge.net>;
Sat, 31 Jan 2015 15:37:52 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.194.61.145 with SMTP id p17mr27584730wjr.35.1422747472024;
Sat, 31 Jan 2015 15:37:52 -0800 (PST)
Received: by 10.194.92.208 with HTTP; Sat, 31 Jan 2015 15:37:51 -0800 (PST)
Received: by 10.194.92.208 with HTTP; Sat, 31 Jan 2015 15:37:51 -0800 (PST)
In-Reply-To: <1348028F-26F8-42CB-9859-C9CB751BF0C9@gmail.com>
References: <27395C55-CF59-4E65-83CA-73F903272C5F@gmail.com>
<CAAt2M18kRgJeNGu9GeKabRpTKPX9rVeoYiKoanz99bmV2jaf4w@mail.gmail.com>
<1348028F-26F8-42CB-9859-C9CB751BF0C9@gmail.com>
Date: Sun, 1 Feb 2015 00:37:51 +0100
Message-ID: <CAAt2M1_3BdKQTVxsN7Hc-W=q0_NWyhBg1UAuSwxRQ8BePDa-8g@mail.gmail.com>
From: Natanael <natanael.l@gmail.com>
To: Brian Erdelyi <brian.erdelyi@gmail.com>
Content-Type: multipart/alternative; boundary=047d7bacc0f2acdcec050dfb35a7
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
(natanael.l[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: 1YHhby-0001bO-1O
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: Sat, 31 Jan 2015 23:37:59 -0000
--047d7bacc0f2acdcec050dfb35a7
Content-Type: text/plain; charset=UTF-8
Den 1 feb 2015 00:05 skrev "Brian Erdelyi" <brian.erdelyi@gmail.com>:
>>
>> See vanitygen. Yes, 8 characters can be brute forced.
>
> Thank you for this reference. Interesting to see that there is a tool to
generate a vanity bitcoin address.
>
> I am still researching viruses that are designed to manipulate a bitcoin
address. I suspect they are primitive in that they use a hardcoded rogue
bitcoin address as opposed to dynamically generating one.
>
> As a start, this would help protect against malware that uses a static
rogue bitcoin address. The next thing would be for the malware to
brute-force the legitimate bitcoin address and generate a rogue bitcoin
address that would produce the same 8 digit code. Curious to know how long
this brute force would take? Or perhaps, before converting to 8 digits
there is some other hashing function that is performed.
>
> Brian Erdelyi
To bruteforce 8 decimals, on average you need (10^8)/2 = 50 000 000 tries.
log(50M)/log(2) = 25.6 bits of entropy.
One try = generate a random number, use it to generate an ECDSA keypair,
SHA256 and RIPEMD160 hash the public key per Bitcoin specs, then run that
OCRA hashing code, then compare strings. Considering the ECDSA operations
is by a large margin slower than all the hash functions, consider them to
just add a small percentage in performance drop vs regular vanitygen usage.
My non-gaming laptop performed IIRC at *a few million keys per second* with
OpenCL. I've used it to search for 6 character strings in the base58
Bitcoin addresses with it in 15 minutes to half an hour or so. That's about
35 bits of entropy (rough estimate, there's some details with padding in
the base58 representation that alters it).
So 2^(35-26) ~= 1 in 500 of that time, and that's if you use a laptop
instead of a GPU rig. Seconds at worst. Milliseconds if done on a rig.
--047d7bacc0f2acdcec050dfb35a7
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<p dir=3D"ltr"><br>
Den 1 feb 2015 00:05 skrev "Brian Erdelyi" <<a href=3D"mailto:=
brian.erdelyi@gmail.com">brian.erdelyi@gmail.com</a>>:<br>
>><br>
>> See vanitygen. Yes, 8 characters can be brute forced.<br>
><br>
> Thank you for this reference.=C2=A0 Interesting to see that there is a=
tool to generate a vanity bitcoin address.<br>
><br>
> I am still researching viruses that are designed to manipulate a bitco=
in address.=C2=A0 I suspect they are primitive in that they use a hardcoded=
rogue bitcoin address as opposed to dynamically generating one.<br>
><br>
> As a start, this would help protect against malware that uses a static=
rogue bitcoin address.=C2=A0 The next thing would be for the malware to br=
ute-force the legitimate bitcoin address and generate a rogue bitcoin addre=
ss that would produce the same 8 digit code.=C2=A0 Curious to know how long=
this brute force would take?=C2=A0 Or perhaps, before converting to 8 digi=
ts there is some other hashing function that is performed.<br>
><br>
> Brian Erdelyi</p>
<p dir=3D"ltr">To bruteforce 8 decimals, on average you need (10^8)/2 =3D 5=
0 000 000 tries. log(50M)/log(2) =3D 25.6 bits of entropy. </p>
<p dir=3D"ltr">One try =3D generate a random number, use it to generate an =
ECDSA keypair, SHA256 and RIPEMD160 hash the public key per Bitcoin specs, =
then run that OCRA hashing code, then compare strings. Considering the ECDS=
A operations is by a large margin slower than all the hash functions, consi=
der them to just add a small percentage in performance drop vs regular vani=
tygen usage. </p>
<p dir=3D"ltr">My non-gaming laptop performed IIRC at *a few million keys p=
er second* with OpenCL. I've used it to search for 6 character strings =
in the base58 Bitcoin addresses with it in 15 minutes to half an hour or so=
. That's about 35 bits of entropy (rough estimate, there's some det=
ails with padding in the base58 representation that alters it). </p>
<p dir=3D"ltr">So 2^(35-26) ~=3D 1 in 500 of that time, and that's if y=
ou use a laptop instead of a GPU rig. Seconds at worst. Milliseconds if don=
e on a rig. </p>
--047d7bacc0f2acdcec050dfb35a7--
|
