{"type":"rich","version":"1.0","author_name":"npub17fjkngg0s0mfx4uhhz6n4puhflwvrhn2h5c78vdr5xda4mvqx89swntr0s","author_url":"https://nostr.ae/npub17fjkngg0s0mfx4uhhz6n4puhflwvrhn2h5c78vdr5xda4mvqx89swntr0s","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2020-02-04\n📝 Original message:\nHey again,\n\nOtherwise Mallory gets two invoices, and wants to know if they're\n\u003e actually the same node.  Inv1 has nodeid N1, routehint Bob-\u003eC1, Inv2 has\n\u003e nodeid N2, routehint Bob-\u003eC2.\n\u003e\n\nI think this attack is interesting. AFAICT my proposal defends against this\nbecause of the way\n`payment_secret` and `decoy_key` are both used to derive the `decoy_scid`\n(but don't trust me, do\nverify that I'm not missing something).\n\nIf Mallory doesn't use both the right `decoy_node_id` and `payment_secret`\nto compute `P_I`, Bob\nwill not decode that to a valid real `scid` and will return an\n`unknown_next_peer` which is good\nfor privacy.\n\nIt seems to me that\nhttps://github.com/lightningnetwork/lightning-rfc/pull/681 cannot defend\nagainst this attack. If both invoices are currently valid, Bob will forward\nan HTLC that uses N1\nwith C2 (because Bob has no way of knowing N1 from the onion, for privacy\nreasons).\nThe only way I'd see to avoid is would be that Alice needs to share her\n`decoy_node_id`s with\nBob (and the mapping to a `decoy_scid`) which means more state to\nmanage...but maybe I'm just\nmissing a better mitigation?\n\nCheers,\nBastien\n\nLe mar. 4 févr. 2020 à 15:09, Bastien TEINTURIER \u003cbastien at acinq.fr\u003e a\nécrit :\n\n\u003e I'm a bit confused, I don't know if the implementation work you're\n\u003e mentioning refers to my proposal\n\u003e or yours :).\n\u003e\n\u003e When you say `temporary id`, could you clarify whether you mean a\n\u003e temporary `node_id` or `scid`?\n\u003e\n\u003e Firstly, need to brute-force the onion against your N keys.\n\u003e\n\u003e\n\u003e This is probably the part that confuses me. Are you talking about Bob or\n\u003e Alice there?\n\u003e Alice can easily have her `decoy_node_id` be derived from her real\n\u003e `node_id`'s privacy key and the\n\u003e `payment_hash` or `payment_preimage`. When she receives a payment, she\n\u003e knows which `decoy_node_id`\n\u003e should have been used so she doesn't need to brute-force.\n\u003e\n\u003e That means Alice doesn't even have to change how she stores invoices. When\n\u003e Alice retrieves the\n\u003e invoice from her DB, if it has the `decoy_node_id` feature bit set, she\n\u003e knows she needs to derive\n\u003e the correct `node_id`. If it doesn't have that feature bit set, it's a\n\u003e \"legacy\" invoice and she has\n\u003e to use her real `node_id`.\n\u003e\n\u003e Now Mallory uses Bob-\u003eC2 to pay to N1 for Inv1. If it works, he knows it's\n\u003e\u003e the same node issuing both invoices.\n\u003e\n\u003e\n\u003e Same, that wouldn't work because Alice can easily detect the mismatch and\n\u003e pretend she can't decrypt\n\u003e the onion (the code doesn't even have to pretend: it will use the expected\n\u003e `node_id` and use the\n\u003e existing error paths).\n\u003e\n\u003e Actually, that was too hasty.\n\u003e\n\u003e\n\u003e Ok I think your second email came to the same conclusions and clarifies it\n\u003e a bit :).\n\u003e\n\u003e It's true that this is code where the developer may easily get confused\n\u003e between keys (but it's a\n\u003e lot simpler than the Sphinx or Noise implementation).\n\u003e\n\u003e However in my opinion it's still simpler than the `scid` state management\n\u003e that needs to happen at\n\u003e Alice and Bob in\n\u003e https://github.com/lightningnetwork/lightning-rfc/pull/681 (but I would\n\u003e need to\n\u003e implement both E2E to be able to fairly judge that).\n\u003e\n\u003e Thanks for the feedback, I'll keep working on improving the proposal.\n\u003e Bastien\n\u003e\n\u003e Le mar. 4 févr. 2020 à 05:29, Rusty Russell \u003crusty at rustcorp.com.au\u003e a\n\u003e écrit :\n\u003e \u003e\n\u003e \u003e Rusty Russell \u003crusty at rustcorp.com.au\u003e writes:\n\u003e \u003e \u003e Bastien TEINTURIER \u003cbastien at acinq.fr\u003e writes:\n\u003e \u003e \u003e\u003e That's of course a solution as well. Even with that though, if Alice\n\u003e opens\n\u003e \u003e \u003e\u003e multiple channels to each of her Bobs,\n\u003e \u003e \u003e\u003e she should use Tor and a different node_id each time for better\n\u003e privacy.\n\u003e \u003e \u003e\n\u003e \u003e \u003e There are two uses for this feature (both of which I started\n\u003e implementing):\n\u003e \u003e \u003e\n\u003e \u003e \u003e 1. Simply always use a temporary id when you have a private channel, to\n\u003e \u003e \u003e    obscure your onchain footprint.  This is a nobrainer.\n\u003e \u003e \u003e\n\u003e \u003e \u003e 2. For an extra layer of transience, apply a new temporary id and new\n\u003e \u003e \u003e    nodeid on every invoice *which applies only for that invoice*.\n\u003e \u003e \u003e\n\u003e \u003e \u003e But implementing the latter securely is fraught!\n\u003e \u003e \u003e\n\u003e \u003e \u003e Firstly, need to brute-force the onion against your N keys.  Secondly,\n\u003e \u003e \u003e if you use a temporary key, then you *don't* end up using the HTLC to\n\u003e \u003e \u003e pay an invoice matching that key, you *MUST* pretend you couldn't\n\u003e \u003e \u003e decrypt the onion!  This applies to all code paths between the two,\n\u003e \u003e \u003e including parsing the TLV, etc: they must ALL return\n\u003e \u003e \u003e WIRE_INVALID_ONION_HMAC.\n\u003e \u003e \u003e\n\u003e \u003e \u003e Otherwise, Mallory can get an invoice, then send malformed payments to\n\u003e \u003e \u003e Alice using the transient key in the invoice and see if she decrypts\n\u003e it.\n\u003e \u003e\n\u003e \u003e Actually, that was too hasty.  You can use the payment_hash as a\n\u003e \u003e fastpath:\n\u003e \u003e\n\u003e \u003e 1. Look up invoice using payment_hash.\n\u003e \u003e\n\u003e \u003e 2. If there is an invoice, and it has a temporary id associated with it,\n\u003e \u003e    try using that to decrypt the onion.  If that works, and the onion is\n\u003e \u003e    on the final hop, and the TLV decodes, and the payment_secret is\n\u003e \u003e    correct, you can go back and use this temporary key to decrypt the\n\u003e onion.\n\u003e \u003e    Otherwise, go back and use the normal node key.\n\u003e \u003e\n\u003e \u003e That's still quite a bit of tricky code though...\n\u003e \u003e\n\u003e \u003e Cheers,\n\u003e \u003e Rusty.\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20200204/41cc31da/attachment-0001.html\u003e"}