Re: [Lightning-dev] Decoy node_ids and short_channel_ids
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. ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] DRAFT: interactive tx construction protocol
Rusty had some suggestions about how to improve the protocol messages for this, namely adding a serial_id to the inputs and outputs, which can then be reused for deletions. The serial id can then also be used as the ordering heuristic for transaction inputs during construction (replacing current usage of BIP69). Inputs can be shared amongst peers by flipping the bottom bit of the serial_id before relaying them to another peer (as your own). See below for details. 1. type: 440 `tx_add_input` > > 2. data: > > * [`32*byte`:`channel_identifier`] > * [`32*byte`:``serial_id`] Add a serial id. Each input addition must have a unique serial id. No addition may have a repeated id number. The initiator's serial id's must be odd. The non-initiator's serial id's must be even. Serial ids are used as sorting heuristic for input ordering in final transaction, replaces BIP69 * [`u64`:`sats`] > > * [`sha256`:`prevtx_txid`] > > * [`u32`:`prevtx_vout`] > > * [`u16`:`prevtx_scriptpubkey_len`] > > * [`prevtx_scriptpubkey_len*byte`:`prevtx_scriptpubkey`] > > * [`u16`:`max_witness_len`] > > * [`u16`:`scriptlen`] > > * [`scriptlen*byte`:`script`] > > Removes the signal_rbf; everything will be flagged as RBF eligible. (This makes verifying RBF eligibility during a RBF round simpler.) > 1. type: 442 `tx_add_output` > > 2. data: > > * [`32*byte`:`channel_identifier`] > * [`16*byte`:`serial_id`] Add a serial id. Same rules as for inputs, but a distinct counter set is used. Used for ordering the transactions’ outputs, replacing BIP69 > * [`u64`:`sats`] > > * [`u16`:`scriptlen`] > > * [`scriptlen*byte`:`script`] > > 1. type: 444 `tx_remove_input` > > 2. data: > > * [`32*byte`:`channel_identifier`] > * [`16*byte`:`serial_id`] Input to remove identified by the serial id, not txid and index. > > 1. type: 446 `tx_remove_output` > > 2. data: > > * [`32*byte`:`channel_identifier`] > * [`16*byte`:`serial_id] Output to remove identified by the serial id, not output script and amount. > 1. type: 448 `tx_complete` > > 2. data: > > * [`32*byte`:`channel_identifier`] > Total counts removed from tx_complete. The txid exchanged in the `tx_sigs` will serves as a checksum for the transaction. > 1. type: 448 `tx_sigs` > > 2. data: > > * [`channel_id`:`channel_identifier`] > > * [`u16`:`num_witnesses`] > > * [`num_witnesses*witness_stack`:`witness_stack`] > > 1. subtype: `witness_stack` > > 2. data: > * [`u16`:`num_input_witness`] > > * [`num_input_witness*witness_element`:`witness_element`] > prev_out and prev_txid are removed; witnesses ordered implicitly by serial_id. > 1. subtype: `witness_element` > > 2. data: > > * [`u16`:`len`] > > * [`len*byte`:`witness`] > > > > ## General Notes > > - All output scripts must be standard > > - nLocktime is always set to 0x > - If a blockheight to be used as nLocktime is communicated in the initiation step, is set to blockheight-6; otherwise set to zero- - Serial ids should be chosen at random - For multiparty constructions, the initiator MUST flip the bottom bit of any received inputs before relaying them to a peer. - Collisions of serial ids between peers is a protocol error ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Decoy node_ids and short_channel_ids
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 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 a > écrit : > > > > Rusty Russell writes: > > > Bastien TEINTURIER 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
Re: [Lightning-dev] Sphinx and Push Notifications
darosior via Lightning-dev writes: > Hi Pavol, > >> 1) Is c-lightning going to support Sphinx or other form of >> spontaneous payments? > > I think cdecker is working on integrating keysend to his noise plugin > (https://github.com/lightningd/plugins/pull/68). The keysend functionality is implemented in the noise plugin and I am planning to pull the keysend part out of the plugin, since that part is really trivial to implement (`htlc_accepted` hook that checkes the payment_hash against the preimage in the onion, then tell `lightningd` to resolve directly). As a side note: Sphinx-send is a terrible misnomer, since sphinx is the name of our onion construction, keysend is the proper name to use in this case. >> 2) Can a lightning node (such as lnd or c-lightning) send a push >> notification (e.g. to a webhook) when it receives or routes a >> payment? If yes, is this notification cryptographically signed (for >> example with the node's private key)? Is this documented somewhere? > > C-lightning sends notifications (and hooks, but it doesn't seem to be > your usecase here) for typical events such as "I received an HTLC > !". You can make a plugin which registers to these lightningd > notifications sends encrypted push notifs. Doc here > https://lightning.readthedocs.io/PLUGINS.html#event-notifications :-). You can have a plugin subscribe to HTLC related events (such as `forward_event` [1], or `invoice_payment` [2], to get notified about forwardings or invoices being paid. What you do with that notification then is up to you. It could queue the event in kafka, call out to a webhook, or log a message with a log management system. You can arbitrarily transform the event in the plugin, including issuing calls to `signmessage` which will create a signature for the event message, thus allowing you to prove authenticity of the message. You'd most likely need to canonicalize the message before signing, since JSON is not the best format for canonical serialization, i.e., decoding and re-encoding can result in subtle changes, which could then fail signature verification, but that should not be a major issue. Cheers, Christian ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Decoy node_ids and short_channel_ids
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 a écrit : > > Rusty Russell writes: > > Bastien TEINTURIER 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. ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Sphinx and Push Notifications
2) lnd is getting the API you need in the next release (v0.10), that let you subscribe to HTLC events. See PR https://github.com/lightningnetwork/lnd/pull/3848. The notification won't be signed (but the stream uses TLS), but that can easily be added using the `signmessage` API: https://api.lightning.community/#signmessage Cheers, Johan On Sun, Feb 2, 2020 at 1:46 PM Pavol Rusnak via Lightning-dev wrote: > > Hi all! > > I have a couple of unrelated questions, hope you can give me some pointers. > > 1) Is c-lightning going to support Sphinx or other form of spontaneous > payments? > > 2) Can a lightning node (such as lnd or c-lightning) send a push notification > (e.g. to a webhook) when it receives or routes a payment? If yes, is this > notification cryptographically signed (for example with the node's private > key)? Is this documented somewhere? > > Thanks! > > -- > Best Regards / S pozdravom, > > Pavol "stick" Rusnak > CTO, SatoshiLabs > ___ > Lightning-dev mailing list > Lightning-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
