Topic: Check if your BTC-key is vulnerable - page 3. (Read 18289 times)

Very nice tool, thanks

This is true, but as below it was a reference to past issues.

exactly. bad signing values issue like explained in the first post.




not all forker adapted updates to their fork-branches and clones.

the BTC wallet for android is fixed and "secure" regarding rng issue.

But that page says it was fixed with the "current" updates as of 2013. And the OP is talking currently of 2015.

Perhaps referring to the bad rng on android from about 18 months ago:
https://bitcoin.org/en/alert/2013-08-11-android

Can you say which droid wallets use it? Thanks for posting this.

Most of my bitcoins are already on paper wallets from a clean Ubunutu system (not connected to internet, old printer not connected to internet, etc). But I still have to use a hot wallet sometimes to pay people.

yes mostly online wallets/service. but sadly not only online wallets. i saw many droid technologies with same issues. and most problematic is the clones of cryptocoins which use this old android wallet clones. i already warned developers but many don't understand whats not good.

i recommend sandbox system for handling BTC and/or cold-storage (paper & CLEAN usb flash). example I have computer with my bitcoins and only can connect with self writed IR-module for datatranser of signed transactions. so only can go out via IR to my internet-connected computer. and this have script which accept IR data and make rest. all started with little adruino experiment i made with friend

people often don't understand that enviroment must be secure. encryption and passwords is useless when enviroment is not secure. example you have super secured computer with sandbox (VM) and bitcoins safed here. but hacker goes in your computer with worm/expl/trojan and then waits for you type in password or keys and then all is stolen.. so most important thing is secure computer good or make it offline(no network communication i.e. rj45, wifi) when it s for bitcoin.

This is a really good tip , would reccomend it to anyone. Reading this post actually got me a lil bit scared , prolly gonna make some paper wallets brb

WOW!! thanks very much for sharing and for this detailed explanation. very interesting! i also always keep my coin in coldstorage or my bitcoinode which connected via armory.

Hey cool gadget man! Thanks for making it open source. 

Thanks for that explanation and breaking it down so it's easy to understand.

At least only addresses with spent outputs through a web wallet are possibly at risk, so that's good for me as I keep very small amounts in those. Keep your cold storage cold and only keep a small amount in your hot/spending wallets.

THIS IS ONLY FOR EDUCATIONAL PURPOSE. PLEASE DO NOT HARM OTHER!



We don't get private key from the hash. we get it from the scripts.
When a btc-tx is generated it must be signed. but many developers from btc-services code their
own "wallet-system" so they make it all from their software and when their signing procedure resuses
signing values, then it s easy to generate the private key from that. the input scripts of transaction contains
two signature values. i call s and r.  so when we have 2 inputs or more in a transaction or different inputs from different
transaction (of same publickey) and reused r values it s a huge problem for security. ECDSA then allows you recalculate with curve.

formula:
now only sop1 and sop2 is missing! These are hashes of the outputs to be signed. Also this is calculated by OP_CHECKSIG.
so we have all data for calculating private-key.

so i make example now:

Public key: 1BFhrfTTZP3Nw4BNy4eX4KFLsn9ZeijcMm (i take this example because this vulnerability is public already)
my script tell me we have duplicates in transaction: 9ec4bc49e828d924af1d1029cacf709431abbde46d59554b62bc270e3b29c4b1

input script 1:
30440220d47ce4c025c35ec440bc81d99834a624875161a26bf56ef7fdc0f5d52f843ad1022044e1ff2dfd8102cf7a47c21d5c9fd5701610d04953c6836596b4fe9dd2f53e3e0104dbd0c61532279cf72981c3584fc32216e0127699635c2789f549e0730c059b81ae133016a69 c21e23f1859a95f06d52b7bf149a8f2fe4e8535c8a829b449c5ff

input script 2:
30440220d47ce4c025c35ec440bc81d99834a624875161a26bf56ef7fdc0f5d52f843ad102209a5f1c75e461d7ceb1cf3cab9013eb2dc85b6d0da8c3c6e27e3a5a5b3faa5bab0104dbd0c61532279cf72981c3584fc32216e0127699635c2789f549e0730c059b81ae133016a69c2 1e23f1859a95f06d52b7bf149a8f2fe4e8535c8a829b449c5ff

first i must explain you inputs script format header descr:

0x30 = header byte
0x44 = length descriptor (68 bytes)
0x02 = header byte
0x20 = r value length descriptor (32 bytes)
d47ce4c025c35ec440bc81d99834a624875161a26bf56ef7fdc0f5d52f843ad1 the r coordinate as a big endian integer
0x02 = header byte
0x20 = s value length descriptor (32 bytes)
44e1ff2dfd8102cf7a47c21d5c9fd5701610d04953c6836596b4fe9dd2f53e3e the s1 coordinate and 9a5f1c75e461d7ceb1cf3cab9013eb2dc85b6d0da8c3c6e27e3a5a5b3faa5bab the s2 coordinate as a big endian integer
0x01 = hashtype byte
and 04dbd0c61532279cf72981c3584fc32216e0127699635c2789f549e0730c059b81ae133016a69c2 1e23f1859a95f06d52b7bf149a8f2fe4e8535c8a829b449c5ff is the pubkeyhash


ok so now we know how inputs script is formated. now we calculated missing sop1 and sop2 by OP_CHECKSIG():
sop1: c0e2d0a89a348de88fda08211c70d1d7e52ccef2eb9459911bf977d587784c6e
sop2: 17b0f41c8c337ac1e18c98759e83a8cccbc368dd9d89e5f03cb633c265fd0ddc

so we now have a ll data for calculation:


now we can calculate with below formulas: mathcad or sagemath and we get privkey.
plese note p is the order for the field. p = parameter for secp256k1 curve order which bitcoin use.

now we create finite field for calculation:

and calculate decimal private key  inside this field with:

ouput: 88865298299719117682218467295833367085649033095698151055007620974294165995414

so when we encode we get priv-key hex-coded:
c477f9f65c22cce20657faa5b2d1d8122336f851a508a1ed04e479c34985bf96

and when converted to WIF format:
5KJp7KEffR7HHFWSFYjiCUAntRSTY69LAQEX1AUzaSBHHFdKEpQ

i hope this help you understand.

also: here is implementation for calculating by software: https://gist.github.com/nlitsme/dda36eeef541de37d996
hope it's clear and helped.
thank you

Great work. Can u please provide a step by step method to run this ?

Hmm very interesting thanks for sharing. Can you explain further how a private key get's leaked through a tx hash? i remember people talking about this was a counter-party bug and other online wallets, but I never actually understood how someone can get the PK from a tx hash.

Hi,

thought maybe someone can use the script below. I just wrote it to check couple of my public keys for reused R-signing values which allow generating of the private key of affected PKs. The script is very lightweight and uses urllib2 for loading the data from blockchain.info. So no local btc-node is needed. The script only works for keys with up to 50 tx. If your key got more than 50 tx you have to add some lines (add loop and use optional API-parameters limit and offset to parse through all transactions [50+]). Also the script contains a lot of debug-output which you can just comment or remove.
This is OpenSource and BETA software - USE AT OWN RISK - released under GNU Public License.



if you have question ask me.
thank you.