ok, so how badly do people want this?
I can implement a command line PBKDF2 wallet.dat generator(in Java) if enough people would use it.
-bm
Topic: Safer Brainwallet with Multi-Hash (Read 2679 times)
I've always wanted to use a brain wallet, but I've heard that they are easy to crack so I've stayed away.. Looks like things are changing..
legendary
Activity: 1302
Merit: 1008
Core dev leaves me neg feedback #abuse #political
Does this have any side effects we may not be aware of?
Nobody has mentioned the human element, the software or website you use with a custom algorithm may change their algorithm, or disappear, leaving you wondering how to rehash your pass phrase to make it work...
I've already solved that problem for Electrum users:
https://bitcointalksearch.org/topic/electrum-seed-recovery-stand-alone-python-script-612143
Does this have any side effects we may not be aware of?
Nobody has mentioned the human element, the software or website you use with a custom algorithm may change their algorithm, or disappear, leaving you wondering how to rehash your pass phrase to make it work...
JF,
Could you point us to the explanation of entropy loss in this situation?
we do double hashing elsewhere in Bitcoin btw- http://bitcoin.stackexchange.com/questions/8443/where-is-double-hashing-performed-in-bitcoin/8461#8461
certainly entropy loss could be a potential problem.
thanks, -bm
Could you point us to the explanation of entropy loss in this situation?
we do double hashing elsewhere in Bitcoin btw- http://bitcoin.stackexchange.com/questions/8443/where-is-double-hashing-performed-in-bitcoin/8461#8461
certainly entropy loss could be a potential problem.
thanks, -bm
Please read what DeathandTaxes said about KDFs.
If you take the first one he mentions, PBKDF2,
you can see that the salt is used at each stage
of iteration.
http://en.wikipedia.org/wiki/PBKDF2
I'm far from an expert, but the principle here
is that constant re-hashing introduces
the possibility of convergence.
Now whether that is just a theoretical possibility,
or has been shown to actually occur, I have no
idea. But, by re-introducing entropy at each
round, that problem is mitigated.
2 hashes are fine, but 100,000 hashes might not be.
yes, this looks like the right standard for this. Of course this invites in the 'NSA conspiracy' discussion but certainly standards are favorable to 'roll ur own'.
in the case of PBKDF2 you have a 'c' parameter similar to the exponent I just described. I'll try and read D&T closer next time.
-bm
legendary
Activity: 1302
Merit: 1008
Core dev leaves me neg feedback #abuse #political
JF,
Could you point us to the explanation of entropy loss in this situation?
we do double hashing elsewhere in Bitcoin btw- http://bitcoin.stackexchange.com/questions/8443/where-is-double-hashing-performed-in-bitcoin/8461#8461
certainly entropy loss could be a potential problem.
thanks, -bm
Could you point us to the explanation of entropy loss in this situation?
we do double hashing elsewhere in Bitcoin btw- http://bitcoin.stackexchange.com/questions/8443/where-is-double-hashing-performed-in-bitcoin/8461#8461
certainly entropy loss could be a potential problem.
thanks, -bm
Please read what DeathandTaxes said about KDFs.
If you take the first one he mentions, PBKDF2,
you can see that the salt is used at each stage
of iteration.
http://en.wikipedia.org/wiki/PBKDF2
I'm far from an expert, but the principle here
is that constant re-hashing introduces
the possibility of convergence.
Now whether that is just a theoretical possibility,
or has been shown to actually occur, I have no
idea. But, by re-introducing entropy at each
round, that problem is mitigated.
2 hashes are fine, but 100,000 hashes might not be.
Electrum uses the same principle -- although
it is not using a peer-reviewed KDF, it does
a concatenation of the original seed with
each hashing round.
You could use your idea of a variable exponent
but it should be using this principle, not merely
using the simple loop the OP suggested.
JF,
Could you point us to the explanation of entropy loss in this situation?
we do double hashing elsewhere in Bitcoin btw- http://bitcoin.stackexchange.com/questions/8443/where-is-double-hashing-performed-in-bitcoin/8461#8461
certainly entropy loss could be a potential problem.
thanks, -bm
Could you point us to the explanation of entropy loss in this situation?
we do double hashing elsewhere in Bitcoin btw- http://bitcoin.stackexchange.com/questions/8443/where-is-double-hashing-performed-in-bitcoin/8461#8461
certainly entropy loss could be a potential problem.
thanks, -bm
legendary
Activity: 1302
Merit: 1008
Core dev leaves me neg feedback #abuse #political
I suggest an option to hash the passphrase multiple times.
This will be barely noticeable for the user but will make bruteforcing much more expensive.
This tiny code, added at brainwallet.org's HTML at line 9086, does the trick:
This will be barely noticeable for the user but will make bruteforcing much more expensive.
This tiny code, added at brainwallet.org's HTML at line 9086, does the trick:
Code:
for (var i = 0; i < 100000; i++) {
key = Crypto.SHA256(key, { asBytes: false });
}
key = Crypto.SHA256(key, { asBytes: false });
}
for even better security, the user can specify a hashing exponent. This makes brute forcing incredibly difficult because it's adds an entirely new dimension to the search space.
Code:
for (var i = 0; i < exponent; i++) {
key = Crypto.SHA256(key, { asBytes: false });
}
key = Crypto.SHA256(key, { asBytes: false });
}
where exponent is an input variable.
thus they can specify a very high number for better security. Of course they must be able to remember this number as well.
-bm
Did you even read the thread? This whole approach is flawed due to potential loss of entropy, regardless of
whether you use a variable or fixed exponent.
I suggest an option to hash the passphrase multiple times.
This will be barely noticeable for the user but will make bruteforcing much more expensive.
This tiny code, added at brainwallet.org's HTML at line 9086, does the trick:
This will be barely noticeable for the user but will make bruteforcing much more expensive.
This tiny code, added at brainwallet.org's HTML at line 9086, does the trick:
Code:
for (var i = 0; i < 100000; i++) {
key = Crypto.SHA256(key, { asBytes: false });
}
key = Crypto.SHA256(key, { asBytes: false });
}
for even better security, the user can specify a hashing exponent. This makes brute forcing incredibly difficult because it's adds an entirely new dimension to the search space.
Code:
for (var i = 0; i < exponent; i++) {
key = Crypto.SHA256(key, { asBytes: false });
}
key = Crypto.SHA256(key, { asBytes: false });
}
where exponent is an input variable.
thus they can specify a very high number for better security. Of course they must be able to remember this number as well.
-bm
I would recommend people not rolling their own cryptography.
warpwallet did and no one stole their coins....YET.
Warp wallet uses scrypt.
does simply using 2^18 rounds of scrypt qualify as a proper (peer reviewed) KDF?
I don't know. I am not a cryptologist. However, it is not an original algorithm that they are using. They are not rolling their own crypto. It is one of the widely accepted algos listed above. They follow up the scrypt with pbkdf2 as well.
legendary
Activity: 1302
Merit: 1008
Core dev leaves me neg feedback #abuse #political
I would recommend people not rolling their own cryptography.
warpwallet did and no one stole their coins....YET.
Warp wallet uses scrypt.
does simply using 2^18 rounds of scrypt qualify as a proper (peer reviewed) KDF?
I would recommend people not rolling their own cryptography.
warpwallet did and no one stole their coins....YET.
Warp wallet uses scrypt.
legendary
Activity: 1302
Merit: 1008
Core dev leaves me neg feedback #abuse #political
The problem of "brainwallet" is the use of weak passpharse. No matter what algorithm you use, people could generate a rainbow table and wait for a hit. A very complex algorithm may slow this process down, but it could be cracked eventually for weak passpharses
another problem of "brainwallet" is the rubber hose attack.
The problem of "brainwallet" is the use of weak passpharse. No matter what algorithm you use, people could generate a rainbow table and wait for a hit. A very complex algorithm may slow this process down, but it could be cracked eventually for weak passpharses
legendary
Activity: 1302
Merit: 1008
Core dev leaves me neg feedback #abuse #political
I would recommend people not rolling their own cryptography.
warpwallet did and no one stole their coins....YET.
Does this have any side effects we may not be aware of?
There is the potential for entropy loss. I would recommend people not rolling their own cryptography. There are standardized Key Derivative functions which have been extensively peer reviewed. PBKDF2, BCrypt, and SCrypt are examples of KDFs.
legendary
Activity: 1302
Merit: 1008
Core dev leaves me neg feedback #abuse #political
Does this have any side effects we may not be aware of?
Rehashing over and over could somehow lead to loss of entropy although
i think that is just a postulation and there's no known attack right now,
but see my post above on how that is easily mitigated.
Does this have any side effects we may not be aware of?
legendary
Activity: 1302
Merit: 1008
Core dev leaves me neg feedback #abuse #political
I suggest an option to hash the passphrase multiple times.
This will be barely noticeable for the user but will make bruteforcing much more expensive.
This tiny code, added at brainwallet.org's HTML at line 9086, does the trick:
This will be barely noticeable for the user but will make bruteforcing much more expensive.
This tiny code, added at brainwallet.org's HTML at line 9086, does the trick:
Code:
for (var i = 0; i < 100000; i++) {
key = Crypto.SHA256(key, { asBytes: false });
}
key = Crypto.SHA256(key, { asBytes: false });
}
Electrum does the same thing but uses the concatenation of the original seed with
each iteration to inject entropy all the way through the process in case the hashing
algorithm starts to converge with large repetitions.
Jump to: