rich1.0npub17fjkngg0s0mfx4uhhz6n4puhflwvrhn2h5c78vdr5xda4mvqx89swntr0shttps://nostr.ae/npub17fjkngg0s0mfx4uhhz6n4puhflwvrhn2h5c78vdr5xda4mvqx89swntr0snjumphttps://nostr.ae📅 Original date posted:2020-02-04 📝 Original message: 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/f31934c0/attachment.html>