3
$\begingroup$

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?

Improve this question
$\endgroup$
0

3 Answers 3

Reset to default
8
$\begingroup$

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.

Improve this answer
$\endgroup$
1
  • $\begingroup$ 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. $\endgroup$
    – james853
    Commented Sep 8, 2013 at 10:47
-1
$\begingroup$

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).

Improve this answer
$\endgroup$
1
  • 1
    $\begingroup$ Sorry to say so, but for the purpose described in the question that Android application is insecure from a cryptographic point of view. One does NOT simply "scramble" passwords via permutation as your app does and expect the results to be any safer than the input. Even hashing them wouldn't suffice for the described scenaria. Instead, there are HMACs and – even better – key derivation functions to handle this case, which your app does not use as far as I checked its internals. $\endgroup$
    – e-sushi
    Commented Jul 13, 2017 at 15:00
-3
$\begingroup$

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"

Improve this answer
$\endgroup$
1
  • $\begingroup$ This is a terrible idea. Even password-based hash functions require that the password is hard to guess, which Hello just isn't. By assuming the attacker knows what you do and only the password is unknown (Kerckhoff's principle), the application of SHA256 twice and repeating the result a few times do almost nothing. Just because something looks complicated does not mean it has any meaningful security. $\endgroup$
    – tylo
    Commented Oct 23, 2017 at 13:38

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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