Topic: [ANN] Offline Bitcoin Brain Wallet --- CoinBrain ! (Read 4145 times)

Sent some
While it is true that a name can be spelled many different ways, one individual will almost certainly always spell their name the same way every time, even after 20 years. It's an extreme corner case where someone changes their name. It's an even more extreme corner case where someone changes their name and forgets their old name. And it's an almost impossibility that someone changes their name, forgets their old name, and has no documentation to show what their old name was whatsoever. At that point, they've probably forgotten the passphrase anyway.

That's not what I meant - I meant use the hash a a password for a website.
Username: CJYP
Password: H(Passphrase + salt), where H is the algorithm your program uses
Since we're not in the future where we can use blockchain-based technology to log in, we have to deal with the reality that people use weak passwords that then get guessed.

A transaction can have arbitrary data. I like this idea too.

Thus why I suggested using a loop. H(x) = SHA-256(Scrypt(CryptoNite(SHA-256(Scrypt(CryptoNite(x)))))) or similar. (Named hash functions are entirely arbitrary btw - use whatever works best)


It seems to me that this can be solved simply by using a different hash function than bitcoin's. Maybe I'm not fully understanding though.
Placing a random salt on the blockchain seems to be an excellent way of increasing the entropy enough (as long as it's different for each user) - but again, I don't understand the math well enough to know for certain if that's enough.

The system works like this:
salt = 14-bit random date (birth of date) + password (average quality human password does 50-bits)
then key stretching adds another 14-bits.

In the end, we get hash of a salted password.
The total strength will be like 78-bits, for a medium quality password.
As for applying same salt on every round, I do not understand what will it give us.

Use the salt as seed for next salt  for each round.

But as far as using a hash of hash, you can build dictionaries of hashes that meet certain characteristics.

For example, if you take the average digit of a sha256 sum it will typically be between 7 and 9.

So you can exclude all hashes from your dictionary that are not between 7 and 9, etc. greatly reducing the possible size of your dictionary and increasing the odds of finding a collision.
Try them and their hash.

It's still pretty damn slim, a very large set, but smaller than 2^256 - so that's why you don't want to use a hash of a hash as your private key.

hash of a hash likely has less than 2^256 possibilities, how much less I don't know. Hash of high entropy random data is 2^256 (well, slightly less - I believe the EEC curve bitcoin uses doesn't go all the way to 2^256 but very close)

You want your private key to be a hash of high entropy random data, and that means it is not safe to use something that is easy to remember, even if you stretch it.

Pass phrases are fine for an encrypted wallet because the hacker has to get your wallet first (and then your pass phrase should be salted) but for something where a public address will be in the blockchain, the private key really needs to be a hash of high entropy random data.

Don't use brain wallets. Especially since addresses tend to be single use and should not be used against once you spend from it.

The idea of key stretching is to use a short password (like 40-bits or 50-bits) and stretch it to the maximum hash, of 128-bits.
In my software I do only 2^14 rounds, so I stretch by 14 bits only.

And guessing the second last (or last) hash would require cracking 2^128 key, instead of 50-bit human password.

something like "S$@PPlUTcfaw" is completely impossible to memorize by the average human.
So how this solves the original problem, of short human passwords?

And how exactly can you salt over 10,000 of SHA hash rounds?

key stretching is useful for website passwords, it's a waste for bitcoin.

In fact it is dangerous for bitcoin - because it means your private key is a hash of a very low entropy limited set (a hash)

With website password it is good because cracking the second to last hash doesn't get you anything, but with bitcoin cracking the second to last hash gets you the private key.

Don't do key stretching unless each hash is salted. And even then, your final hash is from a source with far less entropy than /dev/random

-=-

The only safe way to use a brain wallet is to use two or more passwords in your passphrase - e.g.

Five little ducks went out to play, over the hill and far away.

change that to

Five little ducks S$@PPlUTcfaw went out to play, over the hill and far ##4xcoP)1@cg away.

That may be safe - but to be honest, I'd only use something like that as a passphrase for an encrypted wallet, not for a private key where a generated public address will be on the blockchain.
But that probably actually has more entropy than if you took that phrase and key stretched it, because an attacker doesn't know how many characters or what characters are in the phrase. Key stretched - they know what possible characters and how many.

Isn't safe? I didn't put anything wrong into it.
Well... people can always compile from source. This is Open-Source !

The file was created using InnoSetup/ MS VS C++ redistributable, pyQt4 and Qt4 libraries and py2exe compiler.
So I really don't know why AV doesn't like it.

UPDATE: I have contacted Symatec Norton AntiVirus group, and we will investigate this issue.

Sure I understand that, it becomes to over-whelming of choice and I would prefer to stay with one. Your .exe comes up with security alerts by Norton, I would say it is a low alert but none the less it's a risk to me cause of all these scammers on the marketplace.

http://screens.tinygrab.me/7VmNsdcH8BIvxeuBDsRJL.png

Why would this be?

Seanzqt: More choice with different participants means more healthy and decentralized eco-system.
Also this is a new type of wallet. Brain-wallet with new ideas.

Isn't safe? I didn't put anything wrong into it.
Well... people can always compile from source. This is Open-Source !

I find now a days that there are too MANY damn wallets, people trying to start up new shops. Too overwhelming, I am going to stick with CoinJar...

Plus Norton Internet Security advises me the file isn't safe, so who knows.

Donate BTC:
1zEAtvzgh3GXRq4M9DySzLhamUpBEZpHY

Yea thanks !

The reason, that I avoided using names or places is due to spelling issues for foreigners.
A single family name in Russian: Epёмeнкo.

can be spelled as:
Yeremenko
Yuromenko
Eremenko
Eromenko
Juromenko
or any combination thereof...

of course it may be possible to use Unicode to write in own language. But for now I wanted to avoid spelling issues.

source of randomness:
Some users keep it stable (I use GMail for 10 years), but other change email every year.
Same for phone numbers.
My friend, Uzi, changed 8 (!!) phone numbers in two years. But other friend, didn't change in a decade.
With this, it may be difficult to remember what you had 20 years ago.

As for web version --
this is something I cannot trust, as my password may leak straight into a hacker's hands. (unless it is a simple HTML, that I can download into an offline PC).
hackers can silently replace the generator HTML with something... so no Web version I won't trust very much. For this reason, I store only trivial amounts of BTC in blockchain.info wallet.
And after Diginotar bankruptcy I don't trust SSL/HTTPS either. (my bank is insured by the government).
In my opinion blockchain-based technology might replace SSL/X.509 certificates in the future.

Key salt storage on Blockchain:
Another great idea: is to somehow store key salting hash on blockchain itself. (Ethereum allows to do this easily... but I dunno how-to store anything on the Bitcoin blockchain. Although a few experts were able to embed a few images, there is no how-to for python devs)
Obviously only connected clients can do that, but from desktop.
This will allow to store long, 128-bit salts.

ASICs and SHA algo:
As for hashing change .. well I don't know which one is secure.
Litecoin claimed that their hash is ASIC-proof, yet came KNC miner and built a Scrypt-ASIC.
This field needs more research.

-Technologov

I really like this idea, in concept. Don't have time right now to evaluate the code or mess with the program.

I feel, however, that there are better sources of randomness than a birthday. Maybe have the user input their email address or their name, or their mother's maiden name, or something like that. Just include a warning with bold red text that if they enter false information they have to remember it, because they will lose their bitcoin forever if they don't.

I was actually thinking about making something exactly like this when I get more time (aka, in a month or so), except instead of creating a brain wallet it will create a password that one can use on a website. Since you already have this infrastructure in place, maybe you can beat me to it.
It would solve the problem of long passphrases being possible to guess anyway by using dictionary/Bible/Shakespeare/Youtube/Twitter attacks.

EDIT: One more suggestion, that again I don't know if you implemented or not: Use a hashing algorithm other than SHA-256. That way bitcoin ASICs can't guess it. Or even better, use a cycle of several hashing algorithms.

Also, if you have a donation address I'll donate a little.

All brain wallets are offline.

You should really not have a program think of the "password" to the brain wallet as it would make it much easier for you to forget and the chances of you loosing access to the funds are greater.

Hi,

I'm gonna create a way to make easily memorizable, yet fairly secure,
Bitcoin brain-wallet.

The main problem I'm trying to solve is that powerful computers can attack trillions
of combinations per second.
And the average human password is too short and therefore too weak to withstand such an attack.
So a normal 8-character random password can be cracked in just a few minutes.

After some work, I was able to build a next-generation offline Bitcoin brain wallet with 2 techniques:
key salting and key stretching.

To strengthen normally weak human passwords, I added few additional techniques:
1. Key stretching.
2. Key salting equivalent.

Let’s review each:
1. Key stretching happens after the password was entered, but before Bitcoin keypair was generated. Basically a computer runs 10,000 or more rounds of hashes, recursively, and using previous hash as an input for next generation. For atacker to match us, he will have to run exact same procedure on every try, slowing him down by the same factor for every single attempt to crack our passwords.
in v1.0 the program runs 16384 rounds. This is eqivalent to have a stronger password by 14-bits.
More rounds means more security, but then slow computers (such as ARM or Intel Atom) will not be able to compute hash fast enough, and user-experience will suffer.

2. The standard key salting technique uses a random number, that is stored in a shared database (as in /etc/passwd in UNIX machines), that is recommended to be as big as the key itself, namely 128-bit salt. The salt number is always public. It is used against rainbow attacks, where evil hackers pre-computes hash tables and steal bitcoins from there, once you deposit any.
But it is not possible to remember a random number, so I must resort to something else.
Something that has equal random distribution, everyone remembers, has no spelling errors.
Birth date !
We have 365 possible birth-dates per year. Productive populaion between 20-65 (45 year span) gives us a rough number:~= 16,425 possible birth dates, which adds 14-bits to our password strength via key salting method.

So combining both techniques, I was able to effectively achieve an extra 28-bit of password strength without requiring the human user to memorize this extra data, which should help convert even a medium quality password into a strong one, and a strong password into a great password !

***COIN-BRAIN***
https://sourceforge.net/projects/coinbrain/files/
WhitePaper + sources + Windows Setup !

-"Technologov", 25.Jul.2014.