rich1.0Rusty Russell [ARCHIVE] (npub1zw…hkhpx)https://yabu.me/npub1zw7cc8z78v6s3grujfvcv3ckpvg6kr0w7nz9yzvwyglyg0qu5sjsqhkhpxnjumphttps://yabu.me📅 Original date posted:2020-02-04 📝 Original message: 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.