3

I am attempting to come up with a way of memorizing a seed that could lead to any number of brain wallets for bitcoin. I need multiple wallets because a) I don't want all my eggs in one basket, and b) I want to be able to import small amounts from time to time.

Let's say I came up with a passphrase, and assume it's long enough to be secure. If I was to concatenate a value at the end of the phrase, and increment this each time, it could lead to an infinite amount of brainwallets, ie.

SHA256(passphrase.'1')
SHA256(passphrase.'2') etc...

The only disadvantage I see with this approach is that if somebody, at some point in the future was to stumble upon the seed to the private key (keylogger, brute force etc.), it would be trivial to access all the other wallets.

So I was considering using two rounds of SHA256 instead, but adding a second phrase to the hash value of the first round, like this -

SHA256(SHA256(passphrase.'1').'second phrase')
SHA256(SHA256(passphrase.'2').'second phrase')

I would the use the resulting hash as the input to the brain wallet.

This would mean concatenating ASCII text to the hex of the first SHA256 operation. The reason that I don't want to use the actual numeric value is that I need something that can be done easily over a unix command line (I'm not sure how to do 256-bit math operations). I don't want any custom software involved because there's not that much room in my brain. This would hopefully eliminate the worry that somebody could reverse-engineer the process by which I generate the brain wallets.

I'm worried that if I use the ASCII text to generate a second key, I'm somehow compromising the SHA256 process and making everything less secure.

Is there reason for me to be worried or is my approach secure?

Mike Edward Moras
  • 18,161
  • 12
  • 87
  • 240
james853
  • 33
  • 3

3 Answers3

8

This would hopefully eliminate the worry that somebody could reverse-engineer the process by which I generate the brain wallets.

By Kerckhoffs's principle, you should assume that the adversary already knows the algorithm, and the only thing unknown are the secret keys – in your case, the passphrases.

Therefore, the adversary by definition knows that you are generating the brain wallet passphrases by $w_i = h( h(k_1 || i) || k_2)$ (where $h(x)$ is something like $Hex(SHA2(ASCII(x)))$. So the only things your attacker has to "reverse-engineer" are the two passphrases $k_1$ and $k_2$.

For now, SHA-2 is assumed to be preimage-resistant, which means that the best way of finding $k_1$ and $k_2$ is to simply guess them and see if the result matches any captured output (or, if there is no captured output, see if the result helps unlocking any of your wallets).

Generating different $w_i$ with the same passphrases does not significantly help the attacker to break it, but if he breaks one, also all the others are broken. The encoding (hex, ascii, anything else) doesn't matter for the security, too.

If your two passphrases are good (i.e. having more than 100 bits of entropy together), an attacker has little chance of successing with this brute-force.

If your passphrase is bad (and this includes all passwords with less than 10 characters, or longer ones which can be found in dictionaries), your derivation can be brute-forced easily. Also, if other users are using your scheme too, and by chance have the same password, they'll have the same $w_i$s, which might be usable by an attacker.

Your scheme could be made better by using a slow password hash, and including a salt input which is unique to you, like your email address. The output of this slow hash you can then process with the counter to get the actual $w_i$.

If the attacker has a key-logger and captures your passwords, everything is already lost.

Community
  • 1
Paŭlo Ebermann
  • 22,946
  • 7
  • 82
  • 119
-1

How about using 15+ character passphrase and creating an upper / lowercase seeded permutation of the passphrase. Eg 

My_Pa$$phrase

becomes 

ahpr_a$$()eysM

An attacker, doesn't know your character set, or it's length, so he's left facing an unknown quantity.

Even if he gets hold of one of your scrambled passphrases, is he going to realise what you're doing. How does he know it's not just a high entropy random string.

I produced an Android app using this method here...

play.google.com/store/apps/details?id=appinventor.ai_adrianpeirson60.Pwd_Creator

The description says :

Here are 4 Passwords: notice anything about them ?

K6_0C1I(Y)€m9
€MK(IYC0)_691
k_01y(ci€m9)6
C€69M1IK0)(_Y

They're all upper and lowercase rearrangements of 

Mick€y_1960

There are around 6 Billion Password permutations you can make from 

Mick€y_1960

If you lost your password, 6 Billion is small enough, that you could brute force it. You might need professional help, but it's doable.

This might be ok for medium security, I don't know if I'd feel comfortable if the US Nuclear codes were encrypted using this method, though all things being equal, if an attacker DOESN'T get hold of your password then it's probably safe.

If your scrambled password were 25+ characters long, even if he got hold of one of them, and thus now knows your character set, he still has to brute force your other ones.

You on the other hand can Hash straight to them using your seed value(s).

Mike Edward Moras
  • 18,161
  • 12
  • 87
  • 240
Ade
  • 1
-3

10(*SHA265(SHA256(Hello))

For example is PW:

d7914fe546b684688bb95f4f888a92dfc680603a75f23eb823658031fff766d9d7914fe546b684688bb95f4f888a92dfc680603a75f23eb823658031fff766d9d7914fe546b684688bb95f4f888a92dfc680603a75f23eb823658031fff766d9d7914fe546b684688bb95f4f888a92dfc680603a75f23eb823658031fff766d9d7914fe546b684688bb95f4f888a92dfc680603a75f23eb823658031fff766d9d7914fe546b684688bb95f4f888a92dfc680603a75f23eb823658031fff766d9d7914fe546b684688bb95f4f888a92dfc680603a75f23eb823658031fff766d9d7914fe546b684688bb95f4f888a92dfc680603a75f23eb823658031fff766d9d7914fe546b684688bb95f4f888a92dfc680603a75f23eb823658031fff766d9d7914fe546b684688bb95f4f888a92dfc680603a75f23eb823658031fff766d9

Nobody used it yet and it's simply "hello", now you can do "hello1", "hello2" etc, it would be very tough to "crack"

Chris
  • 1