Topic: Deterministic wallets and security against ECDSA break (Read 907 times)
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.
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).
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).
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.
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.
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.
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.
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.
Jump to: