I found a small weakness in Electrum's key stretching algorithm: The seed-key is only hashed twice.
You should not be hashing anything multiple rounds that needs to maintain entropy. As 256 bits of possible input do not map to a full 256 bits of output (for every two inputs that have a duplicate hash there must be a non-possible hash), repeated hashing reduces entropy further. "Infinity" rounds of hashing may even converge on a vastly reduced output set, but mathematical proof would be a challenge.
Topic: Key stretching weakness (Read 3408 times)
I retort, and say why isn't everything done with cryptographically strong random numbers? Because we must let people be stupid?
That's a reasonable opinion, but you're missing my point: Electrum does hash the seed to generate keypairs. Why is it done for one case but not the other?
You should not be hashing anything multiple rounds that needs to maintain entropy.
SHA256 probably isn't a random oracle, but the entropy loss is small.
I retort, and say why isn't everything done with cryptographically strong random numbers? Because we must let people be stupid?
You should not be hashing anything multiple rounds that needs to maintain entropy.
SHA256 probably isn't a random oracle, but the entropy loss is small. Typical passphrases have far less than 256 bits of entropy. Given those criteria, I think key stretching is beneficial.
Let's say you're right, though, and we shouldn't waste entropy by hashing. Then why is the seed hashed before generating the keys?
I found a small weakness in Electrum's key stretching algorithm: The seed-key is only hashed twice.
You should not be hashing anything multiple rounds that needs to maintain entropy. As 256 bits of possible input do not map to a full 256 bits of output (for every two inputs that have a duplicate hash there must be a non-possible hash), repeated hashing reduces entropy further. "Infinity" rounds of hashing may even converge on a vastly reduced output set, but mathematical proof would be a challenge.
Thanks for the clarification. It's working as designed, then. Why not stretch the wallet key, though?
I found a small weakness in Electrum's key stretching algorithm: The seed-key is only hashed twice. This allows rejecting most passphrases before stretching. It's good for about 8 bits worth of security.
I have sample code here: https://bitcointalksearch.org/topic/m.3546401
I have sample code here: https://bitcointalksearch.org/topic/m.3546401
Electrum's key stretching is not intended to protect the seed against someone having an encrypted seed and bruteforcing AES.
It is there only to make the seed a bit stronger, in case a user uses a custom seed instead of the 128 bits of entropy provided by the software.
more info here: http://stackoverflow.com/questions/11965095/is-it-possible-to-harden-aes-encryption-against-brute-force-attack
I found a small weakness in Electrum's key stretching algorithm: The seed-key is only hashed twice. This allows rejecting most passphrases before stretching. It's good for about 8 bits worth of security.
I have sample code here: https://bitcointalksearch.org/topic/m.3546401
I have sample code here: https://bitcointalksearch.org/topic/m.3546401
Jump to: