From rusty at rustcorp.com.au Wed Sep 7 01:27:47 2016 From: rusty at rustcorp.com.au (Rusty Russell) Date: Wed, 07 Sep 2016 10:57:47 +0930 Subject: [Lightning-dev] [BOLT Draft] Onion Routing Spec In-Reply-To: <20160906112701.GA28919@nex> References: <87wpjl3rzh.fsf@rustcorp.com.au> <20160815120647.GA2595@nex> <87h9ajae48.fsf@rustcorp.com.au> <20160818090622.GA28345@nex> <871t1lefuo.fsf@rustcorp.com.au> <20160819183647.GB15105@lightning.network> <87pop1df71.fsf@rustcorp.com.au> <20160902120822.GA4575@nex> <87y4376q25.fsf@rustcorp.com.au> <20160906112701.GA28919@nex> Message-ID: <87k2eo7b3g.fsf@rustcorp.com.au> Christian Decker writes: > On Mon, Sep 05, 2016 at 11:55:22AM +0930, Rusty Russell wrote: >> Christian Decker writes: >> > I'd like to pick up the conversation about the onion routing protocol >> > again, since we are close to merging our implementation into the >> > lightningd node. >> > >> > As far as I can see we mostly agree on the spec, with some issues that >> > should be deferred until later/to other specs: >> > >> > - Key-rotation policies >> >> OK, I've been thinking about the costs of key-rotation. >> > > I forgot that we have two potential key-rotations: > > - Rotating the key used in transactions that hit the Bitcoin network Oh, that's different, yes. > - Rotating the public key used for the DH shared secret generation > for the onion routing protocol > > For the moment I was concentrating on the latter. Yes. It's the one we need to communicate through the node. >> Change Assumptions: >> 1) We use a "comms" key for each node instead of its ID. >> 2) Nodes send out a new comms key, signed by ID. >> >> That's another 33 bytes each to keep, or 8.25MB. To rotate a comms key, >> we need the new key (33 bytes), and a signature from the id (64 bytes), >> and probably a timestamp, (4 bytes), that's 25.25MB. >> >> That's not too bad if we rotate daily. Probably not if we rotate >> hourly.. > A node's public key used for DH shared secret generation exists > independently of its channels. I think we probably should not bind the > rotation of the key we use to talk to that node to one of its > channels. However, it does make sense to require that a node also has > at least one active channel in order for us to care at all :-) This calculation was per-node, not per-channel. > The comms key approach is in line with what I was thinking as well. > We can bind the new communication key with the channel's existence by > showing a derivation path from the node's (fixed) public key and the > new key. So a node wanting to rotate its communication key just sends > the following: "I am (33 byte), please use key number> (~4 byte) and here is a (64 bytes) that I signed > this rotation off.". The communication overhead is identical to your > proposal, but, since you send only the new key, I think in your > proposal we'd have to churn through all known node ids to find which > one signed the rotation, or where you also using timestamp based > derivation? Hmm, do we lose forward secrecy if we use a BIP32 chain? But we may be able to use another derivation method where we derive key N from key N-1. I'm looking at Laolu... > Another case we could consider is having passive rotations: when an > endpoint announces a channel's existence it also sends its rotation > interval along. Every nodes simply derive the new > key and use that for the DH shared secret generation should they want > to talk to this node. And nodes have a switchover window in which they > accept both (would be necessary in the active rotation as well due to > delays). The passive rotation incurs no communication overhead and can > be bound to the node's channels, so as long as we believe one of its > channels to exist, we rotate its keys. I like the zero-comms overhead! We could in fact use block number to rotate; key 1 is used for the first N blocks, then key 2, etc, with old keys allowed X blocks late, new keys allowed X blocks early? I think we should select some N for the moment, rather than making it configurable. If it's too small it might take a long time for clients to derive the current key: 50 usecs each step is almost half a second for a year-old key if we rotate every 6 blocks. Rotation daily makes that much more approachable... > Possibly a mix of active and passive would make sense, with the active > rotation enabling emergency rotations in case a key was compromised, > but we're in a lot of trouble then anyway :-) In that case, you close the channels and start a new node? Cheers, Rusty.