Rusty Russell <ru...@rustcorp.com.au> writes: > Bastien TEINTURIER <bast...@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. _______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
