{"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:\nI'm a bit confused, I don't know if the implementation work you're\nmentioning refers to my proposal\nor yours :).\n\nWhen you say `temporary id`, could you clarify whether you mean a temporary\n`node_id` or `scid`?\n\nFirstly, need to brute-force the onion against your N keys.\n\n\nThis is probably the part that confuses me. Are you talking about Bob or\nAlice there?\nAlice can easily have her `decoy_node_id` be derived from her real\n`node_id`'s privacy key and the\n`payment_hash` or `payment_preimage`. When she receives a payment, she\nknows which `decoy_node_id`\nshould have been used so she doesn't need to brute-force.\n\nThat means Alice doesn't even have to change how she stores invoices. When\nAlice retrieves the\ninvoice from her DB, if it has the `decoy_node_id` feature bit set, she\nknows she needs to derive\nthe correct `node_id`. If it doesn't have that feature bit set, it's a\n\"legacy\" invoice and she has\nto use her real `node_id`.\n\nNow Mallory uses Bob-\u003eC2 to pay to N1 for Inv1. If it works, he knows it's\n\u003e the same node issuing both invoices.\n\n\nSame, that wouldn't work because Alice can easily detect the mismatch and\npretend she can't decrypt\nthe onion (the code doesn't even have to pretend: it will use the expected\n`node_id` and use the\nexisting error paths).\n\nActually, that was too hasty.\n\n\nOk I think your second email came to the same conclusions and clarifies it\na bit :).\n\nIt's true that this is code where the developer may easily get confused\nbetween keys (but it's a\nlot simpler than the Sphinx or Noise implementation).\n\nHowever in my opinion it's still simpler than the `scid` state management\nthat needs to happen at\nAlice and Bob in https://github.com/lightningnetwork/lightning-rfc/pull/681\n(but I would need to\nimplement both E2E to be able to fairly judge that).\n\nThanks for the feedback, I'll keep working on improving the proposal.\nBastien\n\nLe mar. 4 févr. 2020 à 05:29, Rusty Russell \u003crusty at rustcorp.com.au\u003e a écrit\n:\n\u003e\n\u003e Rusty Russell \u003crusty at rustcorp.com.au\u003e writes:\n\u003e \u003e Bastien TEINTURIER \u003cbastien at acinq.fr\u003e writes:\n\u003e \u003e\u003e That's of course a solution as well. Even with that though, if Alice\nopens\n\u003e \u003e\u003e multiple channels to each of her Bobs,\n\u003e \u003e\u003e she should use Tor and a different node_id each time for better\nprivacy.\n\u003e \u003e\n\u003e \u003e There are two uses for this feature (both of which I started\nimplementing):\n\u003e \u003e\n\u003e \u003e 1. Simply always use a temporary id when you have a private channel, to\n\u003e \u003e    obscure your onchain footprint.  This is a nobrainer.\n\u003e \u003e\n\u003e \u003e 2. For an extra layer of transience, apply a new temporary id and new\n\u003e \u003e    nodeid on every invoice *which applies only for that invoice*.\n\u003e \u003e\n\u003e \u003e But implementing the latter securely is fraught!\n\u003e \u003e\n\u003e \u003e Firstly, need to brute-force the onion against your N keys.  Secondly,\n\u003e \u003e if you use a temporary key, then you *don't* end up using the HTLC to\n\u003e \u003e pay an invoice matching that key, you *MUST* pretend you couldn't\n\u003e \u003e decrypt the onion!  This applies to all code paths between the two,\n\u003e \u003e including parsing the TLV, etc: they must ALL return\n\u003e \u003e WIRE_INVALID_ONION_HMAC.\n\u003e \u003e\n\u003e \u003e Otherwise, Mallory can get an invoice, then send malformed payments to\n\u003e \u003e Alice using the transient key in the invoice and see if she decrypts it.\n\u003e\n\u003e Actually, that was too hasty.  You can use the payment_hash as a\n\u003e fastpath:\n\u003e\n\u003e 1. Look up invoice using payment_hash.\n\u003e\n\u003e 2. If there is an invoice, and it has a temporary id associated with it,\n\u003e    try using that to decrypt the onion.  If that works, and the onion is\n\u003e    on the final hop, and the TLV decodes, and the payment_secret is\n\u003e    correct, you can go back and use this temporary key to decrypt the\nonion.\n\u003e    Otherwise, go back and use the normal node key.\n\u003e\n\u003e That's still quite a bit of tricky code though...\n\u003e\n\u003e Cheers,\n\u003e Rusty.\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20200204/f31934c0/attachment.html\u003e"}