[Lightning-dev] [BOLT Draft] Onion Routing Spec

Rusty Russell rusty at rustcorp.com.au
Tue Sep 27 01:47:44 UTC 2016


(Sorry for delay: travel plus laptop issues...)

Olaoluwa Osuntokun <laolu32 at gmail.com> writes:
> Rusty Russell <rusty at rustcorp.com.au> wrote:
>
>> Each node ID is 33 bytes (pubkey) each channel is 6 bytes (blocknum +
> txnum).
>
> Using blocknum+txnum to identify a channel doesn't account for the
> possibility of a single transaction which opens multiple channels
> concurrently. A possible use-case for such a transaction are coin-joined
> channel openings which obfuscate the relationships being creating with a
> channel opening. You'd need to tack on an extra byte (maybe two) to also
> encode the output index of the channel within the transaction.

Great point.  We should absolutely support this.

> Additionally, identifying channels based solely from
> blockheight+offsets conjures up some re-org safety concerns. It's also
> a bit less "verifiable" than referring via the full outpoint.

A little, but the compactness is worth it.  If you're an SPV node you'll
need a proof, and if you're not you'll know if it's not in the main
chain.

>> The proofs are larger: to prove which IDs owns a channel, each one needs a
>> merkle proof (12 x 32 bytes) plus the funding tx (227 bytes, we can skip
>> some though), the two pubkeys (66 bytes), and a signature of the ID using
>> those pubkeys (128 bytes, schnorr would be 64?).
>
> Are those two pub keys the multi-sig pub keys, or the identity pub keys? In
> either case, only requiring two pub keys to attest-to/authenticate the state
> of a channel is insufficient. With only two signatures, then nodes can
> advertise the same channel several times creating a non-canonical graphs
> resulting in differing network views. If we'd like to eliminate such a
> possibility, then we also need to cryptographically bind the two identities
> to the proof.

Yeah, it's not sufficient to get the multisig keys to sign the ID.

> Using a schnorr multi-signature generated by the four pubkeys
> would remedy this. Validators can use pubkey recovery to extract the "group
> pubkey" from the single signature, ensure it's the result of point addition
> of the four public keys, check the channel isn't closed, then verify the
> signature over the advertisement as normal.

I think this only works if the on-chain keys are Schnorr, right?
Until then, we'd need the ID to sign the pubkeys (or anything which
uniquely identified the channel tx).

> Christian Decker <decker.christian at gmail.com> wrote:
>
>> I forgot that we have two potential key-rotations:
>> - Rotating the key used in transactions that hit the Bitcoin network
>
> If you mean the key included within the 2-of-2 multi-sig, I assume all
> implementations will be using a fresh key with each channel either way, so
> we don't need any explicit rotations here?
>
> I've only been thinking of rotations for the onion pubkeys used for the DH
> shared secret derivation for the onion packets. Identity keys could also
> possibly either be rotated/revoked, or delegated with some sort of
> "certificate".
>
>> Another case we could consider is having passive rotations: when an
>> endpoint announces a channel's existence it also sends its rotation
>> interval along.
>
> IMO a passive rotation scheme is superior due to the bandwidth savings of
> pushing the onion key rotations to the edges themselves. As you said an
> active rotation might be used in the emergency case of a forced key rotation
> due to key compromise.

As you state below (and as confirmed by Adam Back and others I asked at
Blockstream), there is no passive scheme for forward secrecy though
unless we want pairing crypto and magic.  So might as well not rotate
keys in that case.

> Earlier in this email chain I suggested a scheme to regain forward secrecy
> in the case of such a private key leak by requiring nodes to do some upfront
> pre-computation involving an intermediate derivation point. This would still
> allow passive rotation by the edges. However, in practice those
> pre-generated would likely be stored in the same location? So that kinda
> puts us back at the original exploit scenario.
>
> If we were to involve some pairing crypto (IBE style), we would use say
> block hashes to allow nodes to passively derive keys the "source" node is
> able to generate the corresponding private key to...
>
> IMO we need to more clearly state our security model/assumptions here to
> reason about the attack scenarios we'll try to guard against.

Indeed.  Let me try to enumerate the different secrets we need to
protect, and you tell me what I missed?

0 - Wallet privkey(s)
  * Must be online for channel creation.
  * Compromise means all not-in-channel funds can be stolen.

1 - Commit signing bitcoin privkey (per peer)
  * Must be online for channel creation, change and close (ie. always).
  * Compromise means we can collaborate with peer to steal funds in that
    channel. (eg. sign a revoked transaction and give all funds to peer,
    or mutually sign a tx spending the funds to anywhere the attacker wants).

2 - Identity privkey
  * Must be online for channel publishing, fee changes.
  * Compromise means we can advertise new rates (or channel
    unavailability), cutting node off lightning network.

3 - Onion privkey
  * Must be online for routing (ie. always)
  * Compromise means we can decode incoming HTLC offers, maybe send fail failure
    messages.

4 - Low-level comms symmetric key (per peer)
  * Must be online always.
  * Compromise means we can decode all messages to peer, and break
    connections with them (we can't create new HTLCs or change bitcoin
    fees without the commit-signing privkey though).

5 - H-preimage (per invoice)
  * Must be online when creating or accepting payment for invoice
    (always, unless we're routing-only).
  * Compromise means we can lose associated incoming amount.

The simplest scheme is that the first four keys are the same.  That's
horrible for node privacy, since you can see even non-lightning funds.
So let's assume the wallet key is separate.

Separating commit keys from identity key allows nodes to post-hoc
announce channels (by associating them with the public identity) and
also means we can segregate peer privkeys (eg. one process per peer)
which is slightly nicer from a security POV.

Separating onion privkey allows rotation; only a win if we get forward
secrecy (not a win for this node, as much as for the network as a
whole).

The comms symmetric key should be rotated with forward secrecy as
well, for similar reasons.

(We *could* derive all the secrets from a single master secret, but
that's an implementation issue with its own tradeoffs...).

Thoughts?
Rusty.


More information about the Lightning-dev mailing list