Title: Insecure local private keys problem definition (and brainstorming) Post by: marcus_of_augustus on June 28, 2011, 05:22:57 AM If I'm understanding this correctly, the philosophy behind the bitcoin network protocol has been to concentrate the effort in securing network comms. (transaction sends, block transmission, etc) and securing the block chain record (hashing) but leave securing the client nodes private keys up to the end users. However, I think this overlooks the fact that for the send tx. to occur the client has to move around the unencrypted private keys on network connected hardware.
In this sense, we can consider the network connected hardware of the clients to be part of the network and maybe should be treating it as such. The alternative is to tend towards a two-tiered system where web-wallets, exchanges, merchants, etc who need to have clients connected 24/7 will bear the brunt of maintaining network stability, operating with 'live' wallets, while a majority of users who will only briefly connect clients intermittently. Obviously, this will lead towards a more centralised client-server relationship that seems to go counter to the ethos of the project. The problem then: unencrypted private keys must reside and move around on the client's network connected hardware, at some point, for signing of the send transactions to occur and thus any network connected hardware forms part of the bitcoin network at that point in time. In this light, perhaps solutions to consider could involve encrypting the private keys with the same strength of the signing of the send tx themselves (ECDSA) operating under the assumption that the clients machines, PC's, servers, etc, are essentially part of the untrusted network layer. As a brainstorm, is it possible to come up with a cryptological scheme whereby the private keys never need be decrypted on the client machine yet can still perform the signing? Anything else will probably lead to a situation where the long term stable network effectively ends at those nodes that are capable of securing private keys on network connected hardware. Possibly limiting widespread adoption. Title: Re: Insecure local private keys problem definition (and brainstorming) Post by: joan on June 28, 2011, 10:27:36 AM You have probably seen the topics on wallet encryption and brainstorming?
Split private keys (http://forum.bitcoin.org/index.php?topic=19080.0) [PULL] Wallet Private Key Encryption (http://forum.bitcoin.org/index.php?topic=8728.0) Coinsplit (http://forum.bitcoin.org/index.php?topic=20252.0) PS: ECDSA is a signing only algorithm, you can't use it for encryption. Title: Re: Insecure local private keys problem definition (and brainstorming) Post by: JoelKatz on June 28, 2011, 12:45:01 PM As a brainstorm, is it possible to come up with a cryptological scheme whereby the private keys never need be decrypted on the client machine yet can still perform the signing? Yes, absolutely. Walk your transactions to the machine that has your private key, a machine which is not connected to the network, then walk the signed transactions to the machine that has a network connection. It would not be difficult to add commands to the client to import and export transactions. No machine connected to the network need ever have your private key.If I held a large number of BitCoins, this is how I'd protect my savings account. Title: Re: Insecure local private keys problem definition (and brainstorming) Post by: killerstorm on June 28, 2011, 01:05:40 PM unencrypted private keys must reside and move around on the client's network connected hardware, at some point, for signing of the send transactions to occur and thus any network connected hardware forms part of the bitcoin network at that point in time. No, they don't. You can have a dedicated piece of hardware not connected to any network for signing. Then if you want to transact you create a partial (unsigned) transaction on you main computer connected to network, write transaction onto some storage medium, then go to your dedicated signing hardware, plug this storage medium in, review transaction details, sign it and move signed transaction back to your main computer to broadcast it. It is crucial to understand that 1. Transaction can be broadcast from any node. 2. To make a transaction you only need a keypair and input details, but you don't need to be connected to network. Also it is possible to make transactions which require more than one signature. Title: Re: Insecure local private keys problem definition (and brainstorming) Post by: phillipsjk on June 29, 2011, 05:15:19 PM I don't know how novel this idea is, but wallet-less miners (https://forum.bitcoin.org/index.php?topic=19033.msg302527#msg302527) are possible.
Quote from: phillipsjk A miner just needs to know an address to send the coins to as well as a source of entropy (such as intermittent network connections). The miner then generates a throw-away private key/address pair. Upon coin creation, the coins are spent in the same transaction block to the destination address. As has been noted in other threads, the destination wallet does not even have to be on an Internet-connected computer. Edit: |