Concerns regarding deterministic wallet

[DeathAndTaxes]

An additional secuirty advantage of deterministic wallets that wasn't mentioned here is that the user can generate new receiving addresses without providing his AES passphrase to decrypt/encrypt his wallet, by using type-2 key homomorphism. This means that the user would need to decrypt his privkeys only when he wishes to spend coins.

That's exactly how Armory wallets work, right now. 

Plus a lot of other powerful features like watching wallet can be put on webserver allowing site to "know" when deposits are made without exposing the seed or private keys.  This can be done using qt client by setting keypool to zero, generating a large number of keypairs and then exporting only the public keys to the webserver.  However it is "clunky".

[1713242930]

1713242930

[1713242930]

1713242930

[1713242930]

1713242930

[jubalix]

i think i did see one example of veyr similar address from a determnisitc wallet, lead to being able to get a private key

[pmlyon]

Thanks for your detailed response.

Electrum seeds are 128 bit (http://electrum.org/seed.html), which makes them easier to brute force. If one is successfully brute forced, this surely yields a larger 'reward' for a the attacker than just brute forcing private keys directly, as it allows the attacker the reconstruct all private keys in the seeded deterministic wallet.

Assuming I'm correct here, why would the decision for to make the seed for an algorithm that generates multiple private keys only 128 bit, while the private keys themselves are 256 bit?

128 bits is more than sufficient.  There's a reason it was chosen.

Consider that the entire bitcoin network, over the course of the last 4.5 years, has "only" produced about 2⁶⁹ hashes.  You'd have to do about 500 quintillion times that amount of work to have a 50% chance to brute-force a single 128-bit seed.  It's just not feasible.

If that is indeed the case, then perhaps I am just being overly paranoid. Maybe it is the simplification of Electrum's seed (specifically its representations as only a few words) that makes it seem that it could be much more easily brute forced than these calculations suggest.

If someone were to get access to your encrypted wallet file, they would only have to attack your passphrase, correct? Some people could easily have weak passphrases, and then you could get access to the private keys. If deterministic wallets were periodically moved to a new deterministic wallet with a new random seed, this would help to mitigate the threat of offline atttacks.

[etotheipi]

If someone were to get access to your encrypted wallet file, they would only have to attack your passphrase, correct? Some people could easily have weak passphrases, and then you could get access to the private keys. If deterministic wallets were periodically moved to a new deterministic wallet with a new random seed, this would help to mitigate the threat of offline atttacks.

You are correct.  They only have to attack your passphrase.  However, Bitcoin-Qt and Armory both use "key-stretching" which is guaranteed to slow down key guessing by a couple orders of magnitude. 

Bitcoin-Qt uses the simplest version -- the password is hashed 25,000+ times to get the encryption key (the exact number is chosen based on your system's speed).  This means that you either try to brute force the encryption key directly (impossible), or you try guessing the passphrase but requires hashing each guess 25,000+ times.  This dramatically slows down an attacker.  But, GPU acceleration is feasible on this, because hashing is so cheap in terms of RAM and simplicity.

Armory uses something more advanced, related to scrypt.  The password isn't just hashed N times, each hash is saved into a lookup table which is then used for another N lookup operations.  This means that they not only have to do the sequential hashing, but each thread that is guessing passwords needs to have N*64 bytes of dedicated RAM to store the lookup table, and that lookup table is specific to the passphrase being guessed (so threads can't share it).  This makes it pretty much useless to apply GPUs, since much of their speed advantage is due to having only a couple kB fast memory per thread, not megabytes.

Armory also tests your system speed to set the parameters to about 0.25sec.  If you use a single CPU on a completely randomized 6-character password, it would take about 500 years for 50% chance to find the password.  Obviously, attackers may have multiple systems/cores to parallelize this, but they have to use CPUs, because of what's mentioned above.  Therefore, if you use approximately 8 characters of real entropy, it's pretty much useless for someone to try, even if they have extraordinary resources.

Of course, people use weak passphrases.  But there's only so much you can do to protect people from themselves...

[pmlyon]

If someone were to get access to your encrypted wallet file, they would only have to attack your passphrase, correct? Some people could easily have weak passphrases, and then you could get access to the private keys. If deterministic wallets were periodically moved to a new deterministic wallet with a new random seed, this would help to mitigate the threat of offline atttacks.

You are correct.  They only have to attack your passphrase.  However, Bitcoin-Qt and Armory both use "key-stretching" which is guaranteed to slow down key guessing by a couple orders of magnitude. 

Bitcoin-Qt uses the simplest version -- the password is hashed 25,000+ times to get the encryption key (the exact number is chosen based on your system's speed).  This means that you either try to brute force the encryption key directly (impossible), or you try guessing the passphrase but requires hashing each guess 25,000+ times.  This dramatically slows down an attacker.  But, GPU acceleration is feasible on this, because hashing is so cheap in terms of RAM and simplicity.

Armory uses something more advanced, related to scrypt.  The password isn't just hashed N times, each hash is saved into a lookup table which is then used for another N lookup operations.  This means that they not only have to do the sequential hashing, but each thread that is guessing passwords needs to have N*64 bytes of dedicated RAM to store the lookup table, and that lookup table is specific to the passphrase being guessed (so threads can't share it).  This makes it pretty much useless to apply GPUs, since much of their speed advantage is due to having only a couple kB fast memory per thread, not megabytes.

Armory also tests your system speed to set the parameters to about 0.25sec.  If you use a single CPU on a completely randomized 6-character password, it would take about 500 years for 50% chance to find the password.  Obviously, attackers may have multiple systems/cores to parallelize this, but they have to use CPUs, because of what's mentioned above.  Therefore, if you use approximately 8 characters of real entropy, it's pretty much useless for someone to try, even if they have extraordinary resources.

Of course, people use weak passphrases.  But there's only so much you can do to protect people from themselves...

Thanks for the great explanation! I should have realized the clients would do something like this; I use 1Password which does the same with its master password. I still don't think the very occasional security transfer of wallets would hurt, just to easy my paranoia.