Bitcoin Forum
November 13, 2024, 01:10:17 PM *
News: Check out the artwork 1Dq created to commemorate this forum's 15th anniversary
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: Deterministic wallets and security against ECDSA break  (Read 908 times)
TierNolan (OP)
Legendary
*
Offline Offline

Activity: 1232
Merit: 1104


View Profile
August 26, 2013, 09:52:45 AM
 #1

One of the advantages of the RIPEMD160 hash is that single use addresses are protected against an ECDSA break.

The hash function and the ECDSA would have to be broken at the same time for those coins to be stolen.

As long as they don't try to spend their coins once the ECDSA algorithm is broken, attackers can't access the coins, since they don't know the public key.

However, with deterministic wallets, this is not the case.

If an attacker obtains the root public key and the chaincode, then they can generate all private keys (assuming an ECDSA break).  Even a weaker break, where they obtain 1 private keys gets the attacker all later keys in the chain.

It looks like the BIP_32 proposal has 2 chains for each "wallet", an internal and external one.  Is this intended as some kind of protection against that?

One option would be to sweep all funds to alternative addresses whenever you spend anything.  Inherently, that requires accessing the cold storage anyway.

It would be nice if there was a way to get the double protection of standard addresses.  The core problem is that if the online computer can generate all the public keys, then an ECDSA break exposes all private keys.

1LxbG5cKXzTwZg9mjL3gaRE835uNQEteWF
jl2012
Legendary
*
Offline Offline

Activity: 1792
Merit: 1111


View Profile
September 02, 2013, 04:50:22 PM
 #2

One of the advantages of the RIPEMD160 hash is that single use addresses are protected against an ECDSA break.

The hash function and the ECDSA would have to be broken at the same time for those coins to be stolen.

As long as they don't try to spend their coins once the ECDSA algorithm is broken, attackers can't access the coins, since they don't know the public key.

However, with deterministic wallets, this is not the case.

If an attacker obtains the root public key and the chaincode, then they can generate all private keys (assuming an ECDSA break).  Even a weaker break, where they obtain 1 private keys gets the attacker all later keys in the chain.

It looks like the BIP_32 proposal has 2 chains for each "wallet", an internal and external one.  Is this intended as some kind of protection against that?

One option would be to sweep all funds to alternative addresses whenever you spend anything.  Inherently, that requires accessing the cold storage anyway.

It would be nice if there was a way to get the double protection of standard addresses.  The core problem is that if the online computer can generate all the public keys, then an ECDSA break exposes all private keys.

Actually I think it is more secure to use a hash function instead of ECDSA to derive the private keys. In this case, however, the watch-only wallet won't be able to generate new addresses.

Donation address: 374iXxS4BuqFHsEwwxUuH3nvJ69Y7Hqur3 (Bitcoin ONLY)
LRDGENPLYrcTRssGoZrsCT1hngaH3BVkM4 (LTC)
PGP: D3CC 1772 8600 5BB8 FF67 3294 C524 2A1A B393 6517
TierNolan (OP)
Legendary
*
Offline Offline

Activity: 1232
Merit: 1104


View Profile
September 05, 2013, 10:10:28 PM
 #3

Actually I think it is more secure to use a hash function instead of ECDSA to derive the private keys. In this case, however, the watch-only wallet won't be able to generate new addresses.

Right, if it is hash function based, then you can generate lots of "random" keys.

Hash(seed | counter) will give a deterministic wallet, but with each key being separate.

The problem is that it doesn't allow a watching only wallet.

1LxbG5cKXzTwZg9mjL3gaRE835uNQEteWF
gmaxwell
Staff
Legendary
*
Offline Offline

Activity: 4270
Merit: 8805



View Profile WWW
September 09, 2013, 10:48:05 PM
 #4

The primary reason for the inclusion of the private derivation is that the public one has a weakness which is somewhat surprising to users, and so it's easy for them to screw themselves.  And thats if I give you a watching wallet of mine, and then I later "export" a single private key from that wallet you can go zipping around deriving all the other private keys. (likewise, to anyone who has the extended public key, breaking one private key is like compromising the whole chain)

I think our vague plans are in Bitcoin-QT to primarily use the private derivation, while supporting "reoccurring payment" subchains, and never allowing the export of single private keys inside a "reoccurring payment" subchain (except maybe via a debugging interface with pictures of dragons posted on it).

Dabs
Legendary
*
Offline Offline

Activity: 3416
Merit: 1912


The Concierge of Crypto


View Profile
September 13, 2013, 12:45:47 PM
 #5

No offense, but this is why I like and prefer random wallets over deterministic ones. I don't mind storing them all. I just need to make backups more often, not once, but that's a good practice too.

Pages: [1]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!