Subhra Mazumdar [ARCHIVE] on Nostr: 📅 Original date posted:2020-04-01 📝 Original message: Hi ZmnSCPxj, Thanks for ...
📅 Original date posted:2020-04-01
📝 Original message:
Hi ZmnSCPxj,
Thanks for the explanation. Pardon my knowledge in this domain but
what I meant is that sender has malicious intent and wants honest parties
to suffer. So by leaking secrets, I meant not revealing its or receiver's
identity to the forwarding nodes, but somehow manipulating subset of the
nodes so that an attack can be launched in the network. For example,
consider path S->A->B->C->D->E->F->R. If we consider the protocol anonymous
multihop lock, S samples secret x_a,x_b,x_c,x_d,x_e,x_f for the nodes
A,B,C,D,E and F respectively. R gets the key k=x_a+x_b+x_c+x_d+x_e+x_f. If
S colludes with B (possibly leak the value x_c,x_d,x_e,x_f to B), lock
funds C,D,E but then not allowing it to relay funds (possibly do a griefing
attack?). What I meant is that if one totally relies on S for the setup
phase, won't it lead to other vulnerabilities? The situation might sound
unrealistic but I still have doubt whether we guarantee fairness if put our
trust entirely on one single entity.
On Wed, Apr 1, 2020 at 10:39 PM ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:
> Good morning Subhra,
>
> > Commenting on it : "As for ZmnSCPxj's suggestion, I think there is the
> same kind of issue.
> > The secrets we establish with anonymous multi-hops locks are between the
> *sender*
> > and each of the hops. In the route blinding case, what we're adding are
> secrets
> > between the *recipient* and the hops, and we don't want the sender to be
> able to
> > influence those."
> > Is it a good idea to rely entirely on the sender for sampling the
> secrets as well as generating the PTLC? As happens in anonymous multi-hops
> locks, for example. Or as it has been discussed later in the thread, both
> receiver and sender must be involved in creation of PTLC? What happens if
> sender/receiver is/(or both are) corrupted? Can it leak secrets to other
> parties?
>
> If both are corrupted, this brings up the question: who are you hiding any
> information from?
> The corruptor has already corrupted both: there is no security or privacy
> possible, the payment is already totally compromised.
>
> The operation of forwarding nodes is simple enough that in general they
> cannot be attacked: sure, the sender and receiver together knows who they
> are, but forwarding nodes are the ones who advertise themselves in order to
> be forwarded through, so they already are known anyway.
>
> When considering privacy, we should always consider that it is the payment
> as a whole which we want to have privacy: we want that third parties will
> not be able to nail down which particular sender sent to which particular
> receiver.
> Thus if the sender already leaks who it is paying to, that is pretty much
> the entire loss of privacy.
>
> Now, currently on Lightning, in general the receiver does not know the
> sender node.
> (Applications on top of Lightning might have the receiver require the
> sender to provide private data, such as a drop point to send a physical
> product to, but *looking only on Lightning* the sender does not send any of
> its information to the receiver).
>
> However, currently, the exact receiver node has to be known by the sender,
> in order for the sender to make a route to it.
> This is a concern since it may be possible for layer-crossing shenanigans
> to be performed, for example the sender might attempt to eclipse the
> receiver on the Bitcoin blockchain layer and make it lose funds by not
> realizing that a PTLC/HTLC has been timed out (because the eclipse attack
> prevents new blocks from propagating to the receiver, who blithely
> continues to think that the timeout has not been reached when in fact it
> has).
>
> The proposal to have a receiver provide a partial, blinded path gives the
> receiver better privacy protection against the sender: the sender knows it
> is one of a possible number of nodes within some number of hops from a
> particular node, but does not know if it is that exact node, one of its
> neighbors, or one of its neighbor neighbors (etc.) is the actual receiver.
> This should make it harder for the sender to attack the receiver by
> attempting to locate its node and eclipse it at the Bitcoin layer, or other
> blockchain-layer shenanigans.
>
> Now, the argument I make is that while the blinding factors in a
> decorrelated PTLC-based payment may be generated by the sender in order for
> the sender to have path privacy, it is safe for the receiver to provide
> blinding factors to a partial path as well.
> We should remember that the blinding factors are just scalars added to the
> final point/scalar at the ultimate recipient, and the final point/scalar
> pair is completely controlled by the recipient anyway, so it should not be
> an issue here: the point that the sender will target at the first node in
> the receiver-provided partial route is no different from the final point
> that the sender would have targeted if it knew exactly who the receiver is.
>
> Regards,
> ZmnSCPxj
>
--
Yours sincerely,
Subhra Mazumdar.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20200401/95a1e434/attachment-0001.html>;
📝 Original message:
Hi ZmnSCPxj,
Thanks for the explanation. Pardon my knowledge in this domain but
what I meant is that sender has malicious intent and wants honest parties
to suffer. So by leaking secrets, I meant not revealing its or receiver's
identity to the forwarding nodes, but somehow manipulating subset of the
nodes so that an attack can be launched in the network. For example,
consider path S->A->B->C->D->E->F->R. If we consider the protocol anonymous
multihop lock, S samples secret x_a,x_b,x_c,x_d,x_e,x_f for the nodes
A,B,C,D,E and F respectively. R gets the key k=x_a+x_b+x_c+x_d+x_e+x_f. If
S colludes with B (possibly leak the value x_c,x_d,x_e,x_f to B), lock
funds C,D,E but then not allowing it to relay funds (possibly do a griefing
attack?). What I meant is that if one totally relies on S for the setup
phase, won't it lead to other vulnerabilities? The situation might sound
unrealistic but I still have doubt whether we guarantee fairness if put our
trust entirely on one single entity.
On Wed, Apr 1, 2020 at 10:39 PM ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:
> Good morning Subhra,
>
> > Commenting on it : "As for ZmnSCPxj's suggestion, I think there is the
> same kind of issue.
> > The secrets we establish with anonymous multi-hops locks are between the
> *sender*
> > and each of the hops. In the route blinding case, what we're adding are
> secrets
> > between the *recipient* and the hops, and we don't want the sender to be
> able to
> > influence those."
> > Is it a good idea to rely entirely on the sender for sampling the
> secrets as well as generating the PTLC? As happens in anonymous multi-hops
> locks, for example. Or as it has been discussed later in the thread, both
> receiver and sender must be involved in creation of PTLC? What happens if
> sender/receiver is/(or both are) corrupted? Can it leak secrets to other
> parties?
>
> If both are corrupted, this brings up the question: who are you hiding any
> information from?
> The corruptor has already corrupted both: there is no security or privacy
> possible, the payment is already totally compromised.
>
> The operation of forwarding nodes is simple enough that in general they
> cannot be attacked: sure, the sender and receiver together knows who they
> are, but forwarding nodes are the ones who advertise themselves in order to
> be forwarded through, so they already are known anyway.
>
> When considering privacy, we should always consider that it is the payment
> as a whole which we want to have privacy: we want that third parties will
> not be able to nail down which particular sender sent to which particular
> receiver.
> Thus if the sender already leaks who it is paying to, that is pretty much
> the entire loss of privacy.
>
> Now, currently on Lightning, in general the receiver does not know the
> sender node.
> (Applications on top of Lightning might have the receiver require the
> sender to provide private data, such as a drop point to send a physical
> product to, but *looking only on Lightning* the sender does not send any of
> its information to the receiver).
>
> However, currently, the exact receiver node has to be known by the sender,
> in order for the sender to make a route to it.
> This is a concern since it may be possible for layer-crossing shenanigans
> to be performed, for example the sender might attempt to eclipse the
> receiver on the Bitcoin blockchain layer and make it lose funds by not
> realizing that a PTLC/HTLC has been timed out (because the eclipse attack
> prevents new blocks from propagating to the receiver, who blithely
> continues to think that the timeout has not been reached when in fact it
> has).
>
> The proposal to have a receiver provide a partial, blinded path gives the
> receiver better privacy protection against the sender: the sender knows it
> is one of a possible number of nodes within some number of hops from a
> particular node, but does not know if it is that exact node, one of its
> neighbors, or one of its neighbor neighbors (etc.) is the actual receiver.
> This should make it harder for the sender to attack the receiver by
> attempting to locate its node and eclipse it at the Bitcoin layer, or other
> blockchain-layer shenanigans.
>
> Now, the argument I make is that while the blinding factors in a
> decorrelated PTLC-based payment may be generated by the sender in order for
> the sender to have path privacy, it is safe for the receiver to provide
> blinding factors to a partial path as well.
> We should remember that the blinding factors are just scalars added to the
> final point/scalar at the ultimate recipient, and the final point/scalar
> pair is completely controlled by the recipient anyway, so it should not be
> an issue here: the point that the sender will target at the first node in
> the receiver-provided partial route is no different from the final point
> that the sender would have targeted if it knew exactly who the receiver is.
>
> Regards,
> ZmnSCPxj
>
--
Yours sincerely,
Subhra Mazumdar.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20200401/95a1e434/attachment-0001.html>;