Ente (OP)
Legendary
Offline
Activity: 2126
Merit: 1001
|
|
December 02, 2013, 08:16:16 AM |
|
Dear Alan, Goatpig, devs and all,
I have a general wallet question which is partly about BIP32, and partly how Armory will implement it.
1) As I understand it, a seed creates a tree, where each branch itself may form a new branch or whole tree, so to speak. With that, will Armory allow to create multiple "wallets" from one single seed? Right now I use several wallets, for bookkeeping and not mixing up inputs/outputs of different categories. So it would be important that change addresses and inputs only mix within one "wallet" or "wallettree" or whatever it would be called.
With security in mind: 2) From knowing the "public key seed" (or similar) and one single private key, all private keys may be reconstructed. I guess from the "public key seed" and one public address all public addresses may be reconstructed as well then. Is there anything I have to take care of in reality? As long as I only use regular Armory functions (sending and receiving) and don't export stuff and don't share my wallet file, nothing evil should happen? Is there anything to extract from the wallet file without knowing the encryption password? 3) I.e., is the "public key seed" encrypted too?
And, finally: 4) In case I can haz several "wallets" in one file, from one seed: Can I have several, different passwords for each "wallet"?
To make sense of all this: Imagine I now have three wallets. One is my unencrypted playmoney, one is my regular funds, one is my long-term savings (with watch-only wallet), one is funds I manage for mom and grandpa. I don't want to lose all of those in case a keylogger steals my one password. I don't want my long-term savings on my online computer altogether. Will I be able to have all this from one seed, with the new wallet format?
This would be a huge selling point for me, and differentiate Armory even more as a pro wallet, focusing on security and advanced features.
Ente
|
|
|
|
|
|
|
|
|
Once a transaction has 6 confirmations, it is extremely unlikely that an attacker without at least 50% of the network's computation power would be able to reverse it.
|
|
|
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
|
|
|
goatpig
Moderator
Legendary
Offline
Activity: 3668
Merit: 1347
Armory Developer
|
|
December 03, 2013, 02:41:31 PM |
|
Armory doesn't support BIP32 yet. With that in mind I can answer a few of your questions based on the current version of Armory wallets:
1) For now there's coin control to keep your change addresses in check. Besides that point, can't really talk about something we haven't implemented yet ^_^;;
2) Armory private and public keys are derived from their previous iteration. Private key X is derived from private key X-1 and is used to build private key X+1. This is done through modulo operations and injecting extra entropy, so you cannot go from address X to address X-1, or X-n for that matter. No amount of leaked private keys can reveal an Armory root key.
Same goes with public keys. However, any private key can reveal all private keys beyond it: Since X gives X+1, then X can give X+n.
3) The chain code (root public key) isn't encrypted. I think Alan mentioned something about implementing a separate password to encrypt the public key and address comments in the wallet files. You'd have to confirm with him.
4) Assuming we implement that, 3) should answer it.
|
|
|
|
Ente (OP)
Legendary
Offline
Activity: 2126
Merit: 1001
|
|
December 03, 2013, 09:07:32 PM |
|
Thank you for your reply. I believe I understand the current wallet, more or less. My workflow is acceptable, I can wait for some time for BIP32 support. Will BIP32 be among the next features after the current big changes (memory and "internals"), or is it further down the list? Is it winter/spring, or "probably 2014"? Yes, I am asking way too long into the future: Any guess if Armory/BIP32 will have several "wallets" from one seed?
Thanks a lot!
Ente
|
|
|
|
goatpig
Moderator
Legendary
Offline
Activity: 3668
Merit: 1347
Armory Developer
|
|
December 04, 2013, 01:55:10 PM |
|
Thank you for your reply. I believe I understand the current wallet, more or less. My workflow is acceptable, I can wait for some time for BIP32 support. Will BIP32 be among the next features after the current big changes (memory and "internals"), or is it further down the list? Is it winter/spring, or "probably 2014"? Yes, I am asking way too long into the future: Any guess if Armory/BIP32 will have several "wallets" from one seed?
Thanks a lot!
Ente
Frankly I'm not sure where BIP32 is on todo list currently. What I know is that we won't be delving into that until the new wallet file format is out. Any guess if Armory/BIP32 will have several "wallets" from one seed? If you mean creating unrelated children seeds from a common root key, as BIP32 specifies, what I can tell you is we don't have a reason to deviate from BIP32 specification for now. As for possible "Armory flavored" features we may add on top of BIP32 wallets, can't tell just yet.
|
|
|
|
|
gec
Newbie
Offline
Activity: 5
Merit: 0
|
|
August 28, 2014, 09:52:10 AM |
|
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?
|
|
|
|
goatpig
Moderator
Legendary
Offline
Activity: 3668
Merit: 1347
Armory Developer
|
|
August 28, 2014, 02:06:50 PM |
|
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.
|
|
|
|
gec
Newbie
Offline
Activity: 5
Merit: 0
|
|
August 28, 2014, 03:34:22 PM |
|
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.
Okay. Frist of all, thank you very much for the clear and quick answer. And second: Whoa! I had not understood the chaincode to be public -- but as you explain it, it does make perfect sense. What I learned here is that one must trade off the ability to generate child public keys from parent public keys against the ability to expose individual private keys (to e.g. import them into a mobile device for daily spending needs). And on a somewhat related note, now I also understand hardened keys in BIP32 a bit better... Thanks!
|
|
|
|
|