📅 Original date posted:2020-02-04
📝 Original message:
Bastien TEINTURIER <bastien at acinq.fr> 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.
Rusty Russell [ARCHIVE] /
npub1zw…hkhpx
2023-06-09 12:58:34
in reply to nevent1q…7z2c
Author Public Key
npub1zw7cc8z78v6s3grujfvcv3ckpvg6kr0w7nz9yzvwyglyg0qu5sjsqhkhpxPublished at
2023-06-09 12:58:34Event JSON
{
"id": "7f0418c76d441e8a6b4364ad35e7815d4537e8e81d2835995d28d992d5f8ea02",
"pubkey": "13bd8c1c5e3b3508a07c92598647160b11ab0deef4c452098e223e443c1ca425",
"created_at": 1686315514,
"kind": 1,
"tags": [
[
"e",
"3ed35742512a6038c8a47910d5915af4fefd8766015db6ab01e4ef19d4ac6fff",
"",
"root"
],
[
"e",
"afa97f17840afd49c5f3fdca1801c5be433392a080f98322d79834e39d256da6",
"",
"reply"
],
[
"p",
"f26569a10f83f6935797b8b53a87974fdcc1de6abd31e3b1a3a19bdaed8031cb"
]
],
"content": "📅 Original date posted:2020-02-04\n📝 Original message:\nBastien TEINTURIER \u003cbastien at acinq.fr\u003e writes:\n\u003e Hey again,\n\u003e\n\u003e Otherwise Mallory gets two invoices, and wants to know if they're\n\u003e\u003e actually the same node. Inv1 has nodeid N1, routehint Bob-\u003eC1, Inv2 has\n\u003e\u003e nodeid N2, routehint Bob-\u003eC2.\n\u003e\n\u003e I think this attack is interesting. AFAICT my proposal defends against this\n\u003e because of the way\n\u003e `payment_secret` and `decoy_key` are both used to derive the `decoy_scid`\n\u003e (but don't trust me, do\n\u003e verify that I'm not missing something).\n\u003e\n\u003e If Mallory doesn't use both the right `decoy_node_id` and `payment_secret`\n\u003e to compute `P_I`, Bob\n\u003e will not decode that to a valid real `scid` and will return an\n\u003e `unknown_next_peer` which is good\n\u003e for privacy.\n\nBut Mallory can do the same attack, I think. Just include the P_I from\nthe wrong invoice for Bob.\n\n\u003e It seems to me that\n\u003e https://github.com/lightningnetwork/lightning-rfc/pull/681 cannot defend\n\u003e against this attack. If both invoices are currently valid, Bob will forward\n\u003e an HTLC that uses N1\n\u003e with C2 (because Bob has no way of knowing N1 from the onion, for privacy\n\u003e reasons).\n\u003e The only way I'd see to avoid is would be that Alice needs to share her\n\u003e `decoy_node_id`s with\n\u003e Bob (and the mapping to a `decoy_scid`) which means more state to\n\u003e manage...but maybe I'm just\n\u003e missing a better mitigation?\n\nNo, Bob can include the scid he used in the update_add_htlc message, so\nAlice can check.\n\nI'm extremely nervous about custodial lightning services restricting\nwhat they will pay to. This is not theoretical: they will come under\nimmense KYC pressure in the near future, which means they cannot pay\narbitrary invoices.\n\nThus my preference for a system which doesn't add any requirements on\nthe payer.\n\nCheers,\nRusty.",
"sig": "de2507acf8b8370d7115971cb9426892c1addd43cb42542c528e8e958bdc6ae44a59aca02f9c20353e847252950ff3e637ab92db9d8fe9930d9766adeabec918"
}