Rusty Russell [ARCHIVE] on Nostr: 📅 Original date posted:2020-02-04 📝 Original message: Bastien TEINTURIER ...
📅 Original date posted:2020-02-04
📝 Original message:
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.
And then I realized that Alice can't do this properly without Bob
telling her what the scid he used to route was.
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.
Now Mallory uses Bob->C2 to pay to N1 for Inv1. If it works, he knows
it's the same node issuing both invoices.
So, update_add_htlc needs a new scid field.
At this point, I think we should just add a new channel_flag, which if
you set it (and feature flag is offered) you get assigned random SCID
from the peer in funding_locked. This overrides your
funding-transaction-based SCID.
That gets the first case for new channels, without adding much
complexity at all.[1]
Thoughts?
Rusty.
[1] If we want to cover existing channels, we need a new "give me a
replacement scid" msg and reply. But it can be idempotent (you
only ever get one replacement).
📝 Original message:
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.
And then I realized that Alice can't do this properly without Bob
telling her what the scid he used to route was.
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.
Now Mallory uses Bob->C2 to pay to N1 for Inv1. If it works, he knows
it's the same node issuing both invoices.
So, update_add_htlc needs a new scid field.
At this point, I think we should just add a new channel_flag, which if
you set it (and feature flag is offered) you get assigned random SCID
from the peer in funding_locked. This overrides your
funding-transaction-based SCID.
That gets the first case for new channels, without adding much
complexity at all.[1]
Thoughts?
Rusty.
[1] If we want to cover existing channels, we need a new "give me a
replacement scid" msg and reply. But it can be idempotent (you
only ever get one replacement).