Take the 2-minute tour ×
Cryptography Stack Exchange is a question and answer site for software developers, mathematicians and others interested in cryptography. It's 100% free, no registration required.

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?

share|improve this question

1 Answer 1

up vote 4 down vote accepted

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.

share|improve this answer
    
Thank you for this. So as I understand it, there's no meaningful advantage in increasing the complexity of the way you chain encryption algorithms vs. simply adding more entropy to the key? Ie. instead of thinking "The attacker will never guess to run SHA256 37 times in a row", it is better to add a corresponding amount of entropy to the key and run SHA256 once? The slow password hash bit makes complete sense to me, I shall look into bcrypt. –  james853 Sep 8 '13 at 10:47

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.