Topic: (Successful) Dictionary Attack Against Private Keys - page 2. (Read 9452 times)

So I did a little informal study of this on IRC with a little test page, and it was basically impossible convince people that their personal information wasn't being "connected" to their account in some way.  (and to some extent it is: someone who had their credentials recovered would have a harder time denying them).   This is least recovers from the saltlessness problem, though it leaves the door open for targeted attacks against passwords which are almost never strong enough... but I can't figure out how to get the user past the "personal information" problem.

Remove 1 bitcoin from that address to infom the owner that the key is compromised 

I disagree, it is not a very representative analogy.

Here's why: there is a very high probability that locked houses have valuables inside, and it is possible to make a well judged assessment as to how valuable the contents are to improve your luck even further. There is no way of knowing whether a brain wallet seed leads to funded addresses or how much is in those addresses, you are relying on the partially predictable behaviour of human actors.

Go to service subforum ffs

I have wallet.dat generated with 123000 most common keywords from wordlists.
USE FOR SCIENTIFIC RESEARCH ONLY!!

Buy here: http://satoshibox.com/5228477e4c347bc5590041a7

On a related note, I thought about a partial solution to this problem of weak password based private keys.  My specific use case was deriving the seed for a deterministic wallet from a password on a hardware wallet.  Though, it could certainly be applied elsewhere.  (NOTE: I don't plan to implement this without further thought and experimentation.)

Ask the user for their full name, DOB, and/or any other personal information.  Concat with their password.  Chuck into an unusually expensive KDF, one that could take minutes or more to run.  Save the seed in protected flash on the hardware wallet (inaccessible to the outside world).  Feel free to encrypt that seed with a wallet pin/password (use the usual second long KDF here), if the user desires (for extra protection, and to prevent physical theft of the wallet).

Benefits:  This adds extra entropy that the user already has and can easily remember.  Some information may be difficult for an attacker to acquire (Social Security number, driver's license number, etc).  It mimics existing security restrictions present in the banking system and elsewhere.  By storing the derived seed (securely), the user only needs to enter this information once.  Since this process occurs infrequently we can use a very expensive KDF to make brute forcing painful.  The personal information also helps to make the derived seed unique to each user, even if two users choose the same (stupid) password.

It should be great at mitigating the kind of drive-by thefts demonstrated in this thread.  But, if an attacker has access to some or all of the personal information, then we're back to depending on the user's password choice and the strength of the KDF.  In extreme cases, one could set-up the KDF to take a day.  Again, this happens infrequently for the user (certainly 24 hours is significantly better than the turn-around on a stolen credit card, for example).  But, it would make attackers squirm.  The top 10,000 passwords would take 10,000 CPU-days of effort (now imagine the attacker doesn't know the name of your first dog...).

Look at private key 0000000000000000000000000000000000000000000000000000000000000001

There are also some transactions sent to addresses derived from raw hexadecimal private keys (this was the subject of my very first post, and yes I do now understand why it wraps), for instance ...

DEADBEEFDEADBEEFDEADBEEFDEADBEEFDEADBEEFDEADBEEFDEADBEEFDEADBEEF

5KWMcKxLvqmxBP5u6GcycvpJUdcA8sxZjK8Nm5uKUZsHch6i5K3

https://blockchain.info/address/12XwKrWbrSppJXQuqLyyZ8vVCk2FgaH7DW

And no, I didn't create this myself 

No you didn't.

i just found more goodies at "chocolates"

why would someone send such a small amount of BTC there?  i don't get it...

I am no longer running the attack.  It was only to prove a point, for security awareness.  I have not taken a single uBtc from any account I found.

Good point ^

Maybe. I mean, if the key was "password" then okay sure.  But if you threw three cpu months at it and the key was found as the product of some increasingly powerful analysis that you performed, some product of you and the victim being on a similar mental wavelength... it may reasonably be the case the the only people in the world who know the key are you and the victim.  But you don't know that.

Rather than stressing about it then, I suggest anyone considering doing this think ahead.

Besides, do you go around jiggling the neighbors doors and trying their windows? Why not? How is this different— beyond the possibility of getting caught being substantially reduced?

You probably have a duty to move the bitcoins somewhere safer for them before someone nefarious does and to serve as a warning to others 

It is kind of like finding a stash of cash poorly hidden under a rock in a public park ... and then you could maybe donate them to a charity of your choice? Or if you can't find the owner you could use a finders keepers ethical reasoning to disburse them as you see fit ....

Please don't crap up the utxo set keeping around more of these junk outputs.

When you redeem these things, send them to an OP_RETURN txout with a value of 0.  This will convert the output into fees and prevent a new output from being created in the txout set.

Ok. I sent chocolate and Basketball. Give some more.

I was just doing this out of curiosity.  If I do come across 1000 BTC I will try to find who it belongs to, and if I can't, I will take a small amount (like .5BTC or so) send it to an address I have posted on this forum, and then let it be.  The user will see money has been taken so his key is bad, and then he will google where it went to, and see it went to me.  I will give it back if he contacts me, or keep it if he does not, as a small tip for keeping his money safe.  

EDIT:

Found these two with positive balances:

Prehash: chocolate
Balance: 5.46E-5 BTC
Address: 1DTqPEUuuTeCJAYDadDnoPDKGvqDVFLRJN
Total Received: 5460

Prehash: basketball
Balance: 5.46E-5 BTC
Address: 1PYckPfNVrMWepDBN6Mzb1QqaEWWB4t1bx
Total Received: 5460

People have been very loudly told not to do this and many people don't— sadly, many other people smugly think they are smart enough to do it safely (I would even bet that most posters in this thread are among them). People have been stolen from, those who needed that to learn already learned— many others just blame the victims "Oh, I wouldn't use a key that stupid", ... yes, yes you would.

In any case, you misunderstand my advice there.  I wasn't making that suggestion for the benefit of the victims— they're already doomed through their ignorance and actions.  I was making that suggestion for the benefit of Sothh. There is no good team here.  Once you embark down this path you potentially find keys and have to choose between becoming a thief yourself or sitting passively while some other thief takes the coin. If you don't want to find yourself in that situation, for sake of your own personal ethics, then you shouldn't be trying— you should instead work on educating people to behave more safely... and compromising bad coins appears to be ineffective, due to the aforementioned victim blaming.

It's been already done. Some peoples have huge amount of private keys already imported and a script that check if there is a balance. If there is a deposit then it's automatically transferred to another address. Try a small deposit of 0.01BTC to one of those address and see what happen There is a thread about this somewhere.

Isn't it better to have a few large public failures based on this obvious weakness to inform and teach the community why this is a bad thing to do?   Pretending it's not a problem means more users will make the same dumb mistake because they haven't seen any negative repercussions derive from it.   I'd rather have good guys trying to break our money for the betterment of that money than rely on malicious actors who have all the incentives to maximize the value they extract and do it as covertly as possible to prevent exactly those lessons from being learned.   If security is an arms race, it always makes sense to have a red team of good guys.