From rusty at rustcorp.com.au Wed Feb 5 01:28:43 2020 From: rusty at rustcorp.com.au (Rusty Russell) Date: Wed, 05 Feb 2020 11:58:43 +1030 Subject: [Lightning-dev] Decoy node_ids and short_channel_ids In-Reply-To: References: <87h808cml7.fsf@rustcorp.com.au> <87o8ufatgw.fsf@rustcorp.com.au> <87d0avasbu.fsf@rustcorp.com.au> Message-ID: <875zglbz5g.fsf@rustcorp.com.au> Bastien TEINTURIER writes: > Hey again, > > Otherwise Mallory gets two invoices, and wants to know if they're >> actually the same node. Inv1 has nodeid N1, routehint Bob->C1, Inv2 has >> nodeid N2, routehint Bob->C2. > > I think this attack is interesting. AFAICT my proposal defends against this > because of the way > `payment_secret` and `decoy_key` are both used to derive the `decoy_scid` > (but don't trust me, do > verify that I'm not missing something). > > If Mallory doesn't use both the right `decoy_node_id` and `payment_secret` > to compute `P_I`, Bob > will not decode that to a valid real `scid` and will return an > `unknown_next_peer` which is good > for privacy. But Mallory can do the same attack, I think. Just include the P_I from the wrong invoice for Bob. > It seems to me that > https://github.com/lightningnetwork/lightning-rfc/pull/681 cannot defend > against this attack. If both invoices are currently valid, Bob will forward > an HTLC that uses N1 > with C2 (because Bob has no way of knowing N1 from the onion, for privacy > reasons). > The only way I'd see to avoid is would be that Alice needs to share her > `decoy_node_id`s with > Bob (and the mapping to a `decoy_scid`) which means more state to > manage...but maybe I'm just > missing a better mitigation? No, Bob can include the scid he used in the update_add_htlc message, so Alice can check. I'm extremely nervous about custodial lightning services restricting what they will pay to. This is not theoretical: they will come under immense KYC pressure in the near future, which means they cannot pay arbitrary invoices. Thus my preference for a system which doesn't add any requirements on the payer. Cheers, Rusty.