Bitcoin Forum
December 06, 2016, 10:29:40 AM *
News: Latest stable version of Bitcoin Core: 0.13.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: [1]
  Print  
Author Topic: Insecure local private keys problem definition (and brainstorming)  (Read 892 times)
marcus_of_augustus
Legendary
*
Offline Offline

Activity: 2086



View Profile
June 28, 2011, 05:22:57 AM
 #1

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.


1481020180
Hero Member
*
Offline Offline

Posts: 1481020180

View Profile Personal Message (Offline)

Ignore
1481020180
Reply with quote  #2

1481020180
Report to moderator
1481020180
Hero Member
*
Offline Offline

Posts: 1481020180

View Profile Personal Message (Offline)

Ignore
1481020180
Reply with quote  #2

1481020180
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1481020180
Hero Member
*
Offline Offline

Posts: 1481020180

View Profile Personal Message (Offline)

Ignore
1481020180
Reply with quote  #2

1481020180
Report to moderator
joan
Jr. Member
*
Offline Offline

Activity: 56



View Profile
June 28, 2011, 10:27:36 AM
 #2

You have probably seen the topics on wallet encryption and brainstorming?

Split private keys
[PULL] Wallet Private Key Encryption
Coinsplit

PS: ECDSA is a signing only algorithm, you can't use it for encryption.
JoelKatz
Legendary
*
Offline Offline

Activity: 1386


Democracy is vulnerable to a 51% attack.


View Profile WWW
June 28, 2011, 12:45:01 PM
 #3

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.

I am an employee of Ripple.
1Joe1Katzci1rFcsr9HH7SLuHVnDy2aihZ BM-NBM3FRExVJSJJamV9ccgyWvQfratUHgN
killerstorm
Legendary
*
Offline Offline

Activity: 994



View Profile
June 28, 2011, 01:05:40 PM
 #4

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.

colored coins proof-of-concept: private currencies, stock/bond p2p exchange

Tips and donations: 16v13Fa9cPmfFzpm9mmbWwAkXY4gyY6uh4
phillipsjk
Legendary
*
Offline Offline

Activity: 1008

Let the chips fall where they may.


View Profile WWW
June 29, 2011, 05:15:19 PM
 #5

I don't know how novel this idea is, but wallet-less miners 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: To avoid refunded coins (and a non-empty virtual wallet), Transaction fees should be payed out of fees paid to the miner in the transaction block; likely (approximating) a user-configurable percentage. Errata: miner processing the transaction can decide which transactions are included or not: no fees necessary.

James' OpenPGP public key fingerprint: EB14 9E5B F80C 1F2D 3EBE  0A2F B3DE 81FF 7B9D 5160
Pages: [1]
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!