Hi Goatpig,
However, any private key can reveal all private keys beyond it: Since X gives X+1, then X can give X+n.
That was a very scary statement from you. But on further inspection, it does not seem to be true?
Looking at
https://github.com/etotheipi/BitcoinArmory/blob/master/cppForSwig/EncryptionUtils.cpp#L692 in
ComputeChainedPrivateKey() I see a scalar multiplication of the private key with a mushed-up chaincode value.
Unless the chaincode is disclosed or we figure out the inverse of a scalar multiplication in ECC
private keys should be safe. Would you concur, and lay my fears to rest?
To get PrivKey key X+1 from PrivKey X (and thus any X+n), you need, besides the private key, the chaincode, which is XOR'ed with PubKey X to produce the final multiplier. Thus you can compute forward if you have both, but not backwards (need PubKey X-1 to get the previous multiplier). Obviously I'm not considering a factorization breakthrough that weakens secp256k1.
If what you got from my post was that private keys were derived off of themselves without an outside multiplier (the chaincode), then I apologize for the poor wording. Obviously you need the chaincode. As a matter of fact, in older paper wallets, the chaincode was randomly generated (it's derived from the root key now), and thus the backups came with 2 values: the root key and the chaincode. Losing the chaincode then was as bad as losing the root key.
You should still consider your wallet compromised if you reveal a private key from its chain. The chaincode is considered public data. It lays unencrypted in all wallets (WO included), to extend the public key chain. Armory picks a new public key from the top of the chain every transaction as its change address. With enough transactions, your change will hit keys beyond the private key you revealed and your coins will be as good as gone.
As opposed to the original specification for BIP32, revealing an Armory chained private key doesn't give up your entire wallet so you still have time to move all 'em coins out.
