Rusty Russell [ARCHIVE] on Nostr: 📅 Original date posted:2016-09-06 📝 Original message: Christian Decker ...

📅 Original date posted:2016-09-06
📝 Original message:
Christian Decker <decker.christian at gmail.com> writes:
> On Mon, Sep 05, 2016 at 11:55:22AM +0930, Rusty Russell wrote:
>> Christian Decker <decker.christian at gmail.com> 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 <pubkey> (33 byte), please use key <derivation
> number> (~4 byte) and here is a <signature> (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 <rotation interval> 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.