|
Title: Couldn't the wallet.dat be secured this way? Post by: Rob P. on June 18, 2011, 12:55:51 AM Every address is a public/private key pair.
Currently, that keypair doesn't have a password on it (which is the basis for the issues with someone getting a wallet.dat and then signing transactions to steal your coins). Couldn't there just be a password placed on each keypair during generation? That way, in order to use any address, you'd have to enter the password in order to sign the transaction. This would further allow for each address to have a unique password, the same, or none (if you chose). Talk amongst yourselves. Title: Re: Couldn't the wallet.dat be secured this way? Post by: FreeMoney on June 18, 2011, 04:45:32 AM The private key is the password. A client could be created that doesn't have a wallet. If you want to spend coins you type it in right then.
Title: Re: Couldn't the wallet.dat be secured this way? Post by: Rob P. on June 18, 2011, 10:49:39 AM The private key is the password. A client could be created that doesn't have a wallet. If you want to spend coins you type it in right then. Yes, you have to sign with the private key. However, that's different from a password. You can place a password on the private key. From: http://www.dewinter.com/gnupg_howto/english/GPGMiniHowto-3.html#ss3.1 Quote Finally you have to enter a password (actually passphrase would be more appropriate, since blanks are allowed). This password is used to be able to use the functionality which belongs to your secret key. Title: Re: Couldn't the wallet.dat be secured this way? Post by: willphase on June 18, 2011, 10:57:44 AM https://github.com/bitcoin/bitcoin/pull/232
Will Title: Re: Couldn't the wallet.dat be secured this way? Post by: Rob P. on June 18, 2011, 11:12:50 AM https://github.com/bitcoin/bitcoin/pull/232 Will Knew it was a good idea. ;) Thanks Will. Title: Re: Couldn't the wallet.dat be secured this way? Post by: bcearl on June 18, 2011, 11:12:59 AM Just consider a trojan that does not steal wallet files, but waits until you make a transaction and changes the destination address and amount of coins just before signing.
You can't do anything against that with encryption - in principle. Title: Re: Couldn't the wallet.dat be secured this way? Post by: bcearl on June 18, 2011, 11:21:29 AM https://github.com/bitcoin/bitcoin/pull/232 Will Knew it was a good idea. ;) Thanks Will. It is a good idea depending on your goal. It is a good idea, because you can copy wallet files without fear. It does not protect against stealing from an infected computer where bitcoin is running. Title: Re: Couldn't the wallet.dat be secured this way? Post by: willphase on June 18, 2011, 11:30:12 AM It's all about layered security. There's no silver bullet security solution but making it more difficult to just read the file is a step in the right direction.
Will Title: Re: Couldn't the wallet.dat be secured this way? Post by: Rob P. on June 18, 2011, 11:37:16 AM It is a good idea depending on your goal. It is a good idea, because you can copy wallet files without fear. It does not protect against stealing from an infected computer where bitcoin is running. My goal is to get as much protection as possible. Making the stealing of the wallet.dat file useless, because you won't have the password to the keys. Allowing each address to have a unique password makes even having a trojan on your computer minimized, because if you haven't used the address during the time of the trojan, some of your addresses will still be safe. I minimize my exposure to trojans and viruses by running operating systems that have minimal exposures (e.g. NOT Windows). This step is necessary to make the stealing of the wallet.dat file useless. As stated, there is no silver bullet. Title: Re: Couldn't the wallet.dat be secured this way? Post by: ribuck on June 18, 2011, 04:50:01 PM The Bitcoin protocol includes a scripting facility that could be used this way: for a transaction to be spent, the usual private key would be required, plus a per-transaction user-selected password .
Transaction scripting is not yet fully-implemented, but the potential is there. |