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 ) 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 ; 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> <1348028F-26F8-42CB-9859-C9CB751BF0C9@gmail.com> Date: Sun, 1 Feb 2015 00:37:51 +0100 Message-ID: From: Natanael To: Brian Erdelyi 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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" : >> >> 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


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.=C2=A0 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 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.
>
> 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.
>
> Brian Erdelyi

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.

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.

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).

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.

--047d7bacc0f2acdcec050dfb35a7--