rich1.0npub17fjkngg0s0mfx4uhhz6n4puhflwvrhn2h5c78vdr5xda4mvqx89swntr0shttps://nostr.ae/npub17fjkngg0s0mfx4uhhz6n4puhflwvrhn2h5c78vdr5xda4mvqx89swntr0snjumphttps://nostr.ae📅 Original date posted:2020-02-04 📝 Original message: 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. 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? Cheers, Bastien Le mar. 4 févr. 2020 à 15:09, Bastien TEINTURIER <bastien at acinq.fr> a écrit : > I'm a bit confused, I don't know if the implementation work you're > mentioning refers to my proposal > or yours :). > > When you say `temporary id`, could you clarify whether you mean a > temporary `node_id` or `scid`? > > Firstly, need to brute-force the onion against your N keys. > > > This is probably the part that confuses me. Are you talking about Bob or > Alice there? > Alice can easily have her `decoy_node_id` be derived from her real > `node_id`'s privacy key and the > `payment_hash` or `payment_preimage`. When she receives a payment, she > knows which `decoy_node_id` > should have been used so she doesn't need to brute-force. > > That means Alice doesn't even have to change how she stores invoices. When > Alice retrieves the > invoice from her DB, if it has the `decoy_node_id` feature bit set, she > knows she needs to derive > the correct `node_id`. If it doesn't have that feature bit set, it's a > "legacy" invoice and she has > to use her real `node_id`. > > Now Mallory uses Bob->C2 to pay to N1 for Inv1. If it works, he knows it's >> the same node issuing both invoices. > > > Same, that wouldn't work because Alice can easily detect the mismatch and > pretend she can't decrypt > the onion (the code doesn't even have to pretend: it will use the expected > `node_id` and use the > existing error paths). > > Actually, that was too hasty. > > > Ok I think your second email came to the same conclusions and clarifies it > a bit :). > > It's true that this is code where the developer may easily get confused > between keys (but it's a > lot simpler than the Sphinx or Noise implementation). > > However in my opinion it's still simpler than the `scid` state management > that needs to happen at > Alice and Bob in > https://github.com/lightningnetwork/lightning-rfc/pull/681 (but I would > need to > implement both E2E to be able to fairly judge that). > > Thanks for the feedback, I'll keep working on improving the proposal. > Bastien > > Le mar. 4 févr. 2020 à 05:29, Rusty Russell <rusty at rustcorp.com.au> a > écrit : > > > > 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. > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20200204/41cc31da/attachment-0001.html>