Rusty Russell [ARCHIVE] on Nostr: 📅 Original date posted:2020-02-04 📝 Original message: Rusty Russell <rusty at ...

📅 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.