From rusty at rustcorp.com.au Tue Feb 4 04:29:09 2020 From: rusty at rustcorp.com.au (Rusty Russell) Date: Tue, 04 Feb 2020 14:59:09 +1030 Subject: [Lightning-dev] Decoy node_ids and short_channel_ids In-Reply-To: <87o8ufatgw.fsf@rustcorp.com.au> References: <87h808cml7.fsf@rustcorp.com.au> <87o8ufatgw.fsf@rustcorp.com.au> Message-ID: <87d0avasbu.fsf@rustcorp.com.au> Rusty Russell writes: > Bastien TEINTURIER 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.