[Lightning-dev] Decoy node_ids and short_channel_ids

[Bastien TEINTURIER]

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>