* [Bitcoin-development] Key retirement and key compromise
@ 2013-02-22 23:08 Roy Badami
2013-02-25 9:41 ` Jorge Timón
[not found] ` <20130225172353.GA7782@malakian.dd-wrt>
0 siblings, 2 replies; 6+ messages in thread
From: Roy Badami @ 2013-02-22 23:08 UTC (permalink / raw)
To: bitcoin-development
Has anyone been thinking about providing tools to allow users to cope
with key compromise - or more generally, to manage key retirement etc?
atm, if you suspect that your keys may be liable to compromise then
what would you have to do? You'd have to create a new wallet (on a
new computer? or is it easy to have two coexisting installs on one
computer?) And then you'd have to make one or more payments from the
old wallet to the new wallet, to transfer the coins. It's a pain, and
you've lost your address book, your transaction history, etc. And
unless you keep the old wallet about, too, you're a bit stuck if
someone makes a payment to one of the old addresses. It's something
that most users would baulk at unless they're really sure they're at
significant risk.
Of course, there are a spectrum of scenarios, ranging from having an
unencrypted wallet stolen by someone who knows what it is, through to
deciding that the passphrase you used to use when you only had a few
dollars worth of BTC maybe isn't good enough now you've got tens of
thousands of dollars worth of coins. Or maybe you have no reason to
suspect there is a risk of compromise, but just have a corporate key
management policy that recommends retiring keys after a period of
time.
What would be really nice is for bitcoin to have a big key compromise
button, which would automatically transfer all coins to newly
generated addresses (optionally with a pause between generation and
transaction - to allow for a new wallet backup). Optionally, too, the
compromised/retired addresses could be marked with a flag such that if
someone sends coins to that address bitcoind immediately generates a
transaction to transfer the coins to address(es) which are good.
I know deterministic wallets have many proponents - but personally I
like having a bag of keys - with the idea that over a period of time,
old keys will routinely be retired and their balances automatically
transfered to newly generated keys. If someone really manages to
crack the passphrase on that 10-year-old wallet backup they got hold
of, then if would be nice to minimise the damage they could do...
And, of course, I want a big panic button that allows me to
automatically transfer all my coins to new addresses ASAP if I
suddenly do something stupid, like accidentally type my passphrase
into my IRC window :-)
Thoughts? Is this functionality that there is any interest in
developing within the official client? If there is any interest in
this then obviously the first step would be to specify exactly what
functionality is wanted...
roy
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: [Bitcoin-development] Key retirement and key compromise
2013-02-22 23:08 [Bitcoin-development] Key retirement and key compromise Roy Badami
@ 2013-02-25 9:41 ` Jorge Timón
2013-02-25 19:44 ` Peter Vessenes
[not found] ` <20130225172353.GA7782@malakian.dd-wrt>
1 sibling, 1 reply; 6+ messages in thread
From: Jorge Timón @ 2013-02-25 9:41 UTC (permalink / raw)
To: Roy Badami; +Cc: bitcoin-development
Just create a new wallet and send everything to a new address.
I don't think additional tools for this are needed.
On 2/23/13, Roy Badami <roy@gnomon•org.uk> wrote:
> Has anyone been thinking about providing tools to allow users to cope
> with key compromise - or more generally, to manage key retirement etc?
>
> atm, if you suspect that your keys may be liable to compromise then
> what would you have to do? You'd have to create a new wallet (on a
> new computer? or is it easy to have two coexisting installs on one
> computer?) And then you'd have to make one or more payments from the
> old wallet to the new wallet, to transfer the coins. It's a pain, and
> you've lost your address book, your transaction history, etc. And
> unless you keep the old wallet about, too, you're a bit stuck if
> someone makes a payment to one of the old addresses. It's something
> that most users would baulk at unless they're really sure they're at
> significant risk.
>
> Of course, there are a spectrum of scenarios, ranging from having an
> unencrypted wallet stolen by someone who knows what it is, through to
> deciding that the passphrase you used to use when you only had a few
> dollars worth of BTC maybe isn't good enough now you've got tens of
> thousands of dollars worth of coins. Or maybe you have no reason to
> suspect there is a risk of compromise, but just have a corporate key
> management policy that recommends retiring keys after a period of
> time.
>
> What would be really nice is for bitcoin to have a big key compromise
> button, which would automatically transfer all coins to newly
> generated addresses (optionally with a pause between generation and
> transaction - to allow for a new wallet backup). Optionally, too, the
> compromised/retired addresses could be marked with a flag such that if
> someone sends coins to that address bitcoind immediately generates a
> transaction to transfer the coins to address(es) which are good.
>
> I know deterministic wallets have many proponents - but personally I
> like having a bag of keys - with the idea that over a period of time,
> old keys will routinely be retired and their balances automatically
> transfered to newly generated keys. If someone really manages to
> crack the passphrase on that 10-year-old wallet backup they got hold
> of, then if would be nice to minimise the damage they could do...
>
> And, of course, I want a big panic button that allows me to
> automatically transfer all my coins to new addresses ASAP if I
> suddenly do something stupid, like accidentally type my passphrase
> into my IRC window :-)
>
> Thoughts? Is this functionality that there is any interest in
> developing within the official client? If there is any interest in
> this then obviously the first step would be to specify exactly what
> functionality is wanted...
>
> roy
>
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_d2d_feb
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
--
Jorge Timón
http://freico.in/
http://archive.ripple-project.org/
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: [Bitcoin-development] Key retirement and key compromise
2013-02-25 9:41 ` Jorge Timón
@ 2013-02-25 19:44 ` Peter Vessenes
0 siblings, 0 replies; 6+ messages in thread
From: Peter Vessenes @ 2013-02-25 19:44 UTC (permalink / raw)
To: Jorge Timón; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 1123 bytes --]
We've been toying with the idea of a 'dead' button, one that issues a bunch
of pre-generated txs sending stuff out to a previously secured 'backup' set
of addresses (we don't think in terms of wallets, just keypairs).
In this scenario, you have a long-term storage address (or set of them),
and if you need to hit the panic button, previously signed transactions
send value over to your emergency storage.
If you've mucked around sending / receiving with your long-term storage,
you'd only catch some BTC, not necessarily all, but what's nice is the
panic transaction leaking has lower security requirements than your private
keys -- worst case it's out, and you've got to deal with stuff in emergency
storage, as opposed to losing all your coins.
You could pair this with a server that checks if 'safe' addresses have
'unauthorized' transactions showing up on the blockchain, and you'd have a
reasonable automated security layer. Maybe. :)
I'm interested in thoughts on this approach as well.
Jorge -- I respectfully disagree with you, there are a number of enterprise
scenarios where your method is not appropriate.
[-- Attachment #2: Type: text/html, Size: 1649 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
[parent not found: <20130225172353.GA7782@malakian.dd-wrt>]
* Re: [Bitcoin-development] Key retirement and key compromise
[not found] ` <20130225172353.GA7782@malakian.dd-wrt>
@ 2013-03-25 20:49 ` Roy Badami
2013-03-25 21:10 ` Gregory Maxwell
0 siblings, 1 reply; 6+ messages in thread
From: Roy Badami @ 2013-03-25 20:49 UTC (permalink / raw)
To: Andrew Poelstra; +Cc: bitcoin-development
On Fri, Feb 22, 2013 at 11:08:51PM +0000, I wrote:
> What would be really nice is for bitcoin to have a big key compromise
> button, which would automatically transfer all coins to newly
> generated addresses (optionally with a pause between generation and
> transaction - to allow for a new wallet backup). Optionally, too, the
> compromised/retired addresses could be marked with a flag such that if
> someone sends coins to that address bitcoind immediately generates a
> transaction to transfer the coins to address(es) which are good.
On Mon, Feb 25, 2013 at 09:23:53AM -0800, Andrew Poelstra wrote:
> The problem with automatic transactions would be: by repeatedly sending
> money to an address and seeing if it always moves quickly, an attacker
> can identify (a) that an address is in use, (b) which public key it has
> (if this isn't already public), and (c) that the key is believed to be
> compromised.
I realise on reflection that what I really want is not automatic
transmissions, but a means to revoke an address.
The problem is that after transfering the coins from the compromised
addresses to a new, hopefully safe address, what to do about the fact
that third parties might still try to send me coins to an old,
compromised address. So what I think I'm suggesting is that there
should be an address revocation protocol, such that clients will give
an error if their user tries to send coins to a revoked address.
Unless we think that direct payments to addresses will become
completely obsolete once the payment protocol is in use, in which case
(maybe) this functionality belongs in the payment protocol instead -
but I remain unconvinced of that.
I'm not envisaging something as drastic as changing the rules to make
transactions to revoked addresses invalid - just an overlay protocol.
Although to be useful such a protocol would have to be pretty much
universally implemented by clients.
Thoughts?
roy
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: [Bitcoin-development] Key retirement and key compromise
2013-03-25 20:49 ` Roy Badami
@ 2013-03-25 21:10 ` Gregory Maxwell
2013-03-25 21:35 ` Roy Badami
0 siblings, 1 reply; 6+ messages in thread
From: Gregory Maxwell @ 2013-03-25 21:10 UTC (permalink / raw)
To: Roy Badami; +Cc: bitcoin-development, Andrew Poelstra
On Mon, Mar 25, 2013 at 1:49 PM, Roy Badami <roy@gnomon•org.uk> wrote:
> I'm not envisaging something as drastic as changing the rules to make
> transactions to revoked addresses invalid - just an overlay protocol.
> Although to be useful such a protocol would have to be pretty much
> universally implemented by clients.
That is quite drastic enough, as it requires adding more perpetual
data that must remain in fast lookup for all validating nodes (the set
of revoked 'addresses').
Keep in mind that this is only improvement for what is a usually
inadvisable usage of Bitcoin to begin with... you should not be
reusing addresses.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Bitcoin-development] Key retirement and key compromise
2013-03-25 21:10 ` Gregory Maxwell
@ 2013-03-25 21:35 ` Roy Badami
0 siblings, 0 replies; 6+ messages in thread
From: Roy Badami @ 2013-03-25 21:35 UTC (permalink / raw)
To: Gregory Maxwell; +Cc: bitcoin-development, Andrew Poelstra
On Mon, Mar 25, 2013 at 02:10:53PM -0700, Gregory Maxwell wrote:
> On Mon, Mar 25, 2013 at 1:49 PM, Roy Badami <roy@gnomon•org.uk> wrote:
> > I'm not envisaging something as drastic as changing the rules to make
> > transactions to revoked addresses invalid - just an overlay protocol.
> > Although to be useful such a protocol would have to be pretty much
> > universally implemented by clients.
>
> That is quite drastic enough, as it requires adding more perpetual
> data that must remain in fast lookup for all validating nodes (the set
> of revoked 'addresses').
Maybe it should be possible for addresses to contain expiry dates, so
that revocation lists don't need to hang around forever.
> Keep in mind that this is only improvement for what is a usually
> inadvisable usage of Bitcoin to begin with... you should not be
> reusing addresses.
It may be inadvisable but in many cases it is pretty much unavoidable
as Bitcoin stands today. Granted, the payment protocol will help with
that in many use cases...
roy
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2013-03-25 21:36 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-02-22 23:08 [Bitcoin-development] Key retirement and key compromise Roy Badami
2013-02-25 9:41 ` Jorge Timón
2013-02-25 19:44 ` Peter Vessenes
[not found] ` <20130225172353.GA7782@malakian.dd-wrt>
2013-03-25 20:49 ` Roy Badami
2013-03-25 21:10 ` Gregory Maxwell
2013-03-25 21:35 ` Roy Badami
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox