[IDEA] Multi-level wallet encryption

[ripper234]

I like how the 0.4 wallet has encryption requirements to send funds. How about multi-level encryption?

Let me explain: Currently I have two wallets:
1. A savings wallet, with a "big pile", for which I will only enter the decrypting password on a totally secure linux computer than has only Bitcoin installed
2. A spending wallet, with a "smaller pile" that I use on my day-to-day Windows machine.

Having to maintain two wallets is a pain, specifically because the savings wallet cannot be accesses (except read-only) on my main machine.

What I propose is having multi-level privilage system within the protocol itself, that would help me define a set of rules such as the following:

1. One master password is required to change the ruleset. I will only ever enter this password on a secure computer. With this password, I can define things like "minimum amount of coins that must remain in this wallet", or "maximum Bitcoin sent from this address per period of 100 blocks".

2. Another password, that will let me transact, but only within the ruleset defined with the master password. I will feel safe enough to use this password on my insecure machine, because even if I happen to have a trojan, I cannot spend more than 50 BTC per week, and I'll always have at least 200 BTC in my wallet (if those are the rules I defined with the master password). These guarantees are protocol-level, and cannot be circumvented by hackers.

3. Another read-only password that must be entered just to open the wallet and read its contents. Why not.


I think this could be implemented, and would greatly increase the security/convenience tradeoff of using Bitcoin.

Thoughts?

[1713863700]

1713863700

[1713863700]

1713863700

[1713863700]

1713863700

[1713863700]

1713863700

[ripper234]

I like how the 0.4 wallet has encryption requirements to send funds. How about multi-level encryption?

Let me explain: Currently I have two wallets:
1. A savings wallet, with a "big pile", for which I will only enter the decrypting password on a totally secure linux computer than has only Bitcoin installed
2. A spending wallet, with a "smaller pile" that I use on my day-to-day Windows machine.

Having to maintain two wallets is a pain, specifically because the savings wallet cannot be accesses (except read-only) on my main machine.

What I propose is having multi-level privilage system within the protocol itself, that would help me define a set of rules such as the following:

1. One master password is required to change the ruleset. I will only ever enter this password on a secure computer. With this password, I can define things like "minimum amount of coins that must remain in this wallet", or "maximum Bitcoin sent from this address per period of 100 blocks".

2. Another password, that will let me transact, but only within the ruleset defined with the master password. I will feel safe enough to use this password on my insecure machine, because even if I happen to have a trojan, I cannot spend more than 50 BTC per week, and I'll always have at least 200 BTC in my wallet (if those are the rules I defined with the master password). These guarantees are protocol-level, and cannot be circumvented by hackers.

3. Another read-only password that must be entered just to open the wallet and read its contents. Why not.


I think this could be implemented, and would greatly increase the security/convenience tradeoff of using Bitcoin.

Thoughts?

418 people read this post, and not a single comment?

[DeathAndTaxes]

The problem is that encryption can't  be used to enforce rules.

I like the idea of a multi-password wallet (think checking & savings).  A custom bitcoin client could show for example you have 47BTC in savings and 10.2892389 BTC in checking.  Daily you use the checking password which decrypts the checking addresses.  A compromise of system would limit your coins lost.

The problem with your rules proposal is it wouldn't be "strong" protection.  As far as I understand it the "rules" would be merely enforced by the client.  If I try to send 101BTC the client detects that as invalid and stops me.  If the hacker gets your password they simply copy the wall.dat, use a custom client which ignores all the rules and use the password to decrypt wallet.dat.  The custom client doesn't enforce the "rules" (actually just ignores all rules data in wallet) and happily sends the transactions.  Now if you have two passwords (checking & savings) and hacker got only one of them it limits how much damage he can do but the rules didn't help any.

So in summary:
2 address groups each with different password is strong protection.  A compromised password only compromises some of the addresses.  To implement one would simply need a client which is aware of addresses groupings, knew when to prompt for saving account password, and could display both balances.  Certainly do-able.

Rules based security can only be enforced by the client and no hacker is going to use the valid client meaning it provides no real security.

[ripper234]

The problem is that encryption can't  be used to enforce rules.

I like the idea of a multi-password wallet (think checking & savings).  A custom bitcoin client could show for example you have 47BTC in savings and 10.2892389 BTC in checking.  Daily you use the checking password which decrypts the checking addresses.  A compromise of system would limit your coins lost.

The problem with your rules proposal is it wouldn't be "strong" protection.  As far as I understand it the "rules" would be merely enforced by the client.  If I try to send 101BTC the client detects that as invalid and stops me.  If the hacker gets your password they simply copy the wall.dat, use a custom client which ignores all the rules and use the password to decrypt wallet.dat.  The custom client doesn't enforce the "rules" (actually just ignores all rules data in wallet) and happily sends the transactions.  Now if you have two passwords (checking & savings) and hacker got only one of them it limits how much damage he can do but the rules didn't help any.

So in summary:
2 address groups each with different password is strong protection.  A compromised password only compromises some of the addresses.  To implement one would simply need a client which is aware of addresses groupings, knew when to prompt for saving account password, and could display both balances.  Certainly do-able.

Rules based security can only be enforced by the client and no hacker is going to use the valid client meaning it provides no real security.

This might require a change in the Bitcoin protocol itself, not just a change in the client.
But, I believe the protocol could be changed to support this new kind of restrictions ... perhaps even in a backward-compatible way.
Or perhaps it could be implemented with scripts.

[BitterTea]

I don't think such changes to the protocol are necessary. Here's how a client could implement something like what you suggest, but with real encryption rather than just client side password protection.

For the purposes of this post, "key" = the private EC key that Bitcoin uses to sign transactions, "$key" =  password, passphrase, or other encryption key used to decrypt a Bitcoin "key"

A wallet is broken up into multiple pools of keys. Each pool can have a different $key with which all of its keys are encrypted. Your daily use pool may not be encrypted at all for quick transactions. Your intermediate pool(s) may require increasingly complex passwords. Your super secure saving pool may require a hardware token on which a $key is stored.

I like the idea that even while using a password or passphrase, in the background a public/private $keypair is used to do actual encryption of the key. Rather like GPG encrypts your private keys with a passphrase, this would allow more flexibility in the use of pools. For instance, when you generate a new receiving address, you could assign it to a secure pool without having to enter the passphrase or insert the hardware token.

[ripper234]

I don't think such changes to the protocol are necessary. Here's how a client could implement something like what you suggest, but with real encryption rather than just client side password protection.

For the purposes of this post, "key" = the private EC key that Bitcoin uses to sign transactions, "$key" =  password, passphrase, or other encryption key used to decrypt a Bitcoin "key"

A wallet is broken up into multiple pools of keys. Each pool can have a different $key with which all of its keys are encrypted. Your daily use pool may not be encrypted at all for quick transactions. Your intermediate pool(s) may require increasingly complex passwords. Your super secure saving pool may require a hardware token on which a $key is stored.

I like the idea that even while using a password or passphrase, in the background a public/private $keypair is used to do actual encryption of the key. Rather like GPG encrypts your private keys with a passphrase, this would allow more flexibility in the use of pools. For instance, when you generate a new receiving address, you could assign it to a secure pool without having to enter the passphrase or insert the hardware token.

This is true. However, I don't see how this could be used to implement smarter policies like "Don't spend more than 1 BTC per 10 blocks from this pool". I might be shortsighted though.

[BitterTea]

This is true. However, I don't see how this could be used to implement smarter policies like "Don't spend more than 1 BTC per 10 blocks from this pool". I might be shortsighted though.

Not directly, but you could create a "1 BTC per 10 blocks" unencrypted pool, which has an upper limit of 1 BTC balance, and the client will attempt to "refill" it 10 blocks after its balance decreases.

To send, you would have to provide your $key if sending from an encrypted pool. To refill, you would also have to provide your $key if refilling from an encrypted pool.

[DeathAndTaxes]

Not directly, but you could create a "1 BTC per 10 blocks" unencrypted pool, which has an upper limit of 1 BTC balance, and the client will attempt to "refill" it 10 blocks after its balance decreases.

To send, you would have to provide your $key if sending from an encrypted pool. To refill, you would also have to provide your $key if refilling from an encrypted pool.

IF someone used it on a client that ignored the rules then they simply would send all they wanted from your main account (assuming the have the password).  You can't enforce rules on a client that is compromised and for good security you should assume the client is compromised.  Then only way to have any meaningful security is if you could push rules to the network and the network (i.e. miners) would reject transactions that violate the rules.

In that case compromising the client wouldn't do you any good.  If I have an outstanding rule that no more than 1 BTC from address x can be spent per block then the network would reject any transactions in excess of it. 


Encryption is good for keeping secrets.  It isn't good for making rules.  Trying to use encryption for the wrong task only create the illusion of security.
You can't implement security into the client.  You should assume the hacker has their own client and your wallet.dat.  For higher security you should also assume the attacker has any password you have typed. This is why a checking account vs saving account model would provide some limited security.  If you haven't typed your saving's account password since the computer was compromised then damage is limited to your checking account.

[BitterTea]

Not directly, but you could create a "1 BTC per 10 blocks" unencrypted pool, which has an upper limit of 1 BTC balance, and the client will attempt to "refill" it 10 blocks after its balance decreases.

To send, you would have to provide your $key if sending from an encrypted pool. To refill, you would also have to provide your $key if refilling from an encrypted pool.

IF someone used it on a client that ignored the rules then they simply would send all they wanted from your main account (assuming the have the password).  You can't enforce rules on a client that is compromised and for good security you should assume the client is compromised.  Then only way to have any meaningful security is if you could push rules to the network and the network (i.e. miners) would reject transactions that violate the rules.

In that case compromising the client wouldn't do you any good.  If I have an outstanding rule that no more than 1 BTC from address x can be spent per block then the network would reject any transactions in excess of it. 


Encryption is good for keeping secrets.  It isn't good for making rules.  Trying to use encryption for the wrong task only create the illusion of security.
You can't implement security into the client.  You should assume the hacker has their own client and your wallet.dat.  For higher security you should also assume the attacker has any password you have typed. This is why a checking account vs saving account model would provide some limited security.  If you haven't typed your saving's account password since the computer was compromised then damage is limited to your checking account.

I think you misunderstand my proposal. The pools are secure, they each can have a different password/passphrase/hardware token. The rule based refilling of pools is merely for ripper's convenience. If the attacker acquires the wallet.dat, all they would be able to do without the correct $keys is to steal any bitcoins in the unencrypted pool(s).

[Meni Rosenfeld]

In case you're not already in the loop, there's been some discussions about extending the scripting language used for transaction verification and modify it to allow scripts to be transparent to senders (example). I'm not at all in the know what's going on but it's possible this can be accomplished with the right script.

PS I've been thinking about the same thing for a long while.

[DeathAndTaxes]

I think you misunderstand my proposal. The pools are secure, they each can have a different password/passphrase/hardware token. The rule based refilling of pools is merely for ripper's convenience. If the attacker acquires the wallet.dat, all they would be able to do without the correct $keys is to steal any bitcoins in the unencrypted pool(s).

I get each pool can have unique password.  I even indicated that was a good idea above (checking account vs savings account).

However you abstract away a serious important point:
" The rule based refilling of pools is merely for ripper's convenience"
How does the client follow the rule and move funds from one pool to another (i.e. refill a pool).  It MUST have the password/private key/token/etc for the pool the funds are coming from.  Otherwise how is it doing the refilling? (which is just a transaction from one pool into another pool)?  Attack the client and steal passphrase for the "refilling pool" and transfer out all funds.

Even worse if the pool has to be manually refilled (by user entering password) for larger fund well you have no more security than a single wallet address.  When you enter the password, someone can keylog it, and then create a new transaction to empty the "filling" address to their wallet.

Having multiple "accounts" inside a single wallet is of some security value.  One could have daily transactions from a limited wallet and only periodically (preferably on a secure usb key) transfer funds from the "savings" account pool to "checking" account pool.  This means daily the only thing accessible to keylogger is the checking account which has limited value.

Once you start making rules to transfer funds between accounts *SOMETHING* must be doing that transfering and that something has the key.  Attack the *SOMETHING* and you have the key of the big wallet.  Forget the limited access wallet at that point you just hit the motherload.

[ripper234]

I think you misunderstand my proposal. The pools are secure, they each can have a different password/passphrase/hardware token. The rule based refilling of pools is merely for ripper's convenience. If the attacker acquires the wallet.dat, all they would be able to do without the correct $keys is to steal any bitcoins in the unencrypted pool(s).

I get each pool can have unique password.  I even indicated that was a good idea above (checking account vs savings account).

However you abstract away a serious important point:
" The rule based refilling of pools is merely for ripper's convenience"
How does the client follow the rule and move refill one pool.  It MUST have the password/private key/token/etc for the pool the funds are coming from.  Otherwise how is it doing the refilling? (which is just a transaction from one pool into another pool)?  Attack the client and steal passphrase for the "refilling pool" and transfer out all funds.

If the pool has to be manually refilled (by user entering password) for larger fund well you have no more security than a single wallet address.  When you enter the password, someone can keylog it, and then create a new transaction to empty the "filling" address to their wallet.

This.

[ripper234]

In case you're not already in the loop, there's been some discussions about extending the scripting language used for transaction verification and modify it to allow scripts to be transparent to senders (example). I'm not at all in the know what's going on but it's possible this can be accomplished with the right script.

PS I've been thinking about the same thing for a long while.

Ho Many, I never saw you around here, even though we met in person and you seem to be quite active.
To sidetrack for a second, what's your opinion on this thread (totally unrelated, if you respond please post there)?

[Meni Rosenfeld]

Ho Many, I never saw you around here, even though we met in person and you seem to be quite active.

I am, you're probably not looking hard enough. And not interested enough in mining pool reward systems, which is generally my primary area of contribution.

To sidetrack for a second, what's your opinion on this thread (totally unrelated, if you respond please post there)?

Which thread? Is a link missing?

[ripper234]

Ho Many, I never saw you around here, even though we met in person and you seem to be quite active.

I am, you're probably not looking hard enough. And not interested enough in mining pool reward systems, which is generally my primary area of contribution.

To sidetrack for a second, what's your opinion on this thread (totally unrelated, if you respond please post there)?

Which thread? Is a link missing?

Sorry, this: Alternate Currencies Review.