[Lightning-dev] Decoy node_ids and short_channel_ids

[Rusty Russell]

Rusty Russell <rusty at rustcorp.com.au> writes:
> Bastien TEINTURIER <bastien at acinq.fr> writes:
>> That's of course a solution as well. Even with that though, if Alice opens
>> multiple channels to each of her Bobs,
>> she should use Tor and a different node_id each time for better privacy.
>
> There are two uses for this feature (both of which I started implementing):
>
> 1. Simply always use a temporary id when you have a private channel, to
>    obscure your onchain footprint.  This is a nobrainer.
>
> 2. For an extra layer of transience, apply a new temporary id and new
>    nodeid on every invoice *which applies only for that invoice*.
>
> But implementing the latter securely is fraught!
>
> Firstly, need to brute-force the onion against your N keys.  Secondly,
> if you use a temporary key, then you *don't* end up using the HTLC to
> pay an invoice matching that key, you *MUST* pretend you couldn't
> decrypt the onion!  This applies to all code paths between the two,
> including parsing the TLV, etc: they must ALL return
> WIRE_INVALID_ONION_HMAC.
>
> Otherwise, Mallory can get an invoice, then send malformed payments to
> Alice using the transient key in the invoice and see if she decrypts it.

Actually, that was too hasty.  You can use the payment_hash as a
fastpath:

1. Look up invoice using payment_hash.

2. If there is an invoice, and it has a temporary id associated with it,
   try using that to decrypt the onion.  If that works, and the onion is
   on the final hop, and the TLV decodes, and the payment_secret is
   correct, you can go back and use this temporary key to decrypt the onion.
   Otherwise, go back and use the normal node key.

That's still quite a bit of tricky code though...

Cheers,
Rusty.