Subhra Mazumdar [ARCHIVE] on Nostr: 📅 Original date posted:2020-04-02 📝 Original message: Hi ZmnSCPxj, Thank you ...
📅 Original date posted:2020-04-02
📝 Original message:
Hi ZmnSCPxj,
Thank you for the clarification.I got your point.
On Thu, Apr 2, 2020 at 1:35 PM ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:
> Good morning Subhra,
>
> > Thank you for the clarification. Sorry for misinterpreting the paper of
> anonymous multihop lock. A bit of rephrasing of what I exactly meant and
> apologies for describing vaguely. Following your discussion on griefing
> attack, it is clear the payer and payee wants to intentionally deprive
> intermediate nodes, by colluding. However, by griefing (a misnomer for this
> situation) I didn't mean exactly withholding the solution but something
> like this:
> > Given S->A->B->C->D->E->F->R, S, B and F are controlled by the same
> adversary and considering all the parties have completed the lock phase.
> Now R triggers release phase and F gets x_r from R. However, F adds x_f to
> x_r forwards it directly to B, doesn't complete signature with E and
> cancels the HTLC just before the elapse of expiration time, E terminates
> its HTLC with D and so on. B has x_c+x_d+x_e+x_f+x_r (shared by F and
> shared by S). It continues normally completing payment with A and then S. I
> am not sure whether again this attack makes sense.
>
> If S controls F, then it could have just forwarded F->R directly without
> involving C D E at all, so in both cases C D E would also not earn any
> forwarding fees; instead now C D E learn of this payment, so the collusion
> S B F just unnecessarily leaks its intent to pay R by doing this.
>
> Again, S B F cannot steal funds from C D E by this method, it can only
> grief them, but it could grief C D E by just B and F, not involving any S
> or R, so this does not increase the attack surface at all.
>
> So I do not see the point of this exercise; S controls F anyway, so it
> could just as well have forwarded F->R directly.
>
> Regards,
> ZmnSCPxj
>
>
> >
> > On Thu, Apr 2, 2020 at 6:04 AM ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:
> >
> > > Good morning Subhra,
> > >
> > > > 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.
> > >
> > > Note that in the context of PTLCs, R does not get a key (as in private
> key) of x_a+x_b+x_c+x_d+x_e+x_f.
> > > Instead, R still continues to use its normal private key for claiming
> HTLC/PTLC.
> > > We simply have R generate an adaptor signature first and hand that
> over to F, such that completing the signature and publishing it onchain
> will reveal a secret x_r (which is NOT the node privkey of R).
> > >
> > > What happens really here is that each hop sets up a PTLC.
> > > The sender is responsible for ensuring that the F->R PTLC is equal to
> x_r * G, that E->F is equal to (x_f + x_r) * G, that D->E is equal to (x_e
> + x_f + x_r) * G, and so on.
> > > However, the sender knows only (x_r * G) without knowing x_r, thus it
> never is able to completely control the secret at every point -- the
> receiver knows the other secret as well.
> > >
> > > That is the entire crux of the argument --- *both* sender and receiver
> control the secrets anyway, so it is not controlled by a single entity, at
> least for non-self-payments.
> > >
> > > > 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?).
> > >
> > > Griefing attacks are only possible by not claiming or forwarding the
> attack.
> > > If S and B "collude" to perform a grief, then either B never forwards
> to C, in which case there is no possible way to attack, or C receives it
> and claims it but B does not claim it, in which case B paid out money and
> is now idiotically refusing to claim money.
> > >
> > > Grief attacks are attacks by payers and payees on intermediate nodes
> (S and R attacking A,B,C,D,E,F), and in that case the entire payment secret
> would be known by both S and R anyway.
> > >
> > > So S and B cannot cooperate to perform a griefing attack on the path.
> > >
> > > Regards,
> > > ZmnSCPxj
> > >
> > > >
> > > > 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.
> >
> > --
> > Yours sincerely,
> > Subhra Mazumdar.
>
>
>
--
Yours sincerely,
Subhra Mazumdar.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20200402/0c9a9d1b/attachment-0001.html>;
📝 Original message:
Hi ZmnSCPxj,
Thank you for the clarification.I got your point.
On Thu, Apr 2, 2020 at 1:35 PM ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:
> Good morning Subhra,
>
> > Thank you for the clarification. Sorry for misinterpreting the paper of
> anonymous multihop lock. A bit of rephrasing of what I exactly meant and
> apologies for describing vaguely. Following your discussion on griefing
> attack, it is clear the payer and payee wants to intentionally deprive
> intermediate nodes, by colluding. However, by griefing (a misnomer for this
> situation) I didn't mean exactly withholding the solution but something
> like this:
> > Given S->A->B->C->D->E->F->R, S, B and F are controlled by the same
> adversary and considering all the parties have completed the lock phase.
> Now R triggers release phase and F gets x_r from R. However, F adds x_f to
> x_r forwards it directly to B, doesn't complete signature with E and
> cancels the HTLC just before the elapse of expiration time, E terminates
> its HTLC with D and so on. B has x_c+x_d+x_e+x_f+x_r (shared by F and
> shared by S). It continues normally completing payment with A and then S. I
> am not sure whether again this attack makes sense.
>
> If S controls F, then it could have just forwarded F->R directly without
> involving C D E at all, so in both cases C D E would also not earn any
> forwarding fees; instead now C D E learn of this payment, so the collusion
> S B F just unnecessarily leaks its intent to pay R by doing this.
>
> Again, S B F cannot steal funds from C D E by this method, it can only
> grief them, but it could grief C D E by just B and F, not involving any S
> or R, so this does not increase the attack surface at all.
>
> So I do not see the point of this exercise; S controls F anyway, so it
> could just as well have forwarded F->R directly.
>
> Regards,
> ZmnSCPxj
>
>
> >
> > On Thu, Apr 2, 2020 at 6:04 AM ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:
> >
> > > Good morning Subhra,
> > >
> > > > 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.
> > >
> > > Note that in the context of PTLCs, R does not get a key (as in private
> key) of x_a+x_b+x_c+x_d+x_e+x_f.
> > > Instead, R still continues to use its normal private key for claiming
> HTLC/PTLC.
> > > We simply have R generate an adaptor signature first and hand that
> over to F, such that completing the signature and publishing it onchain
> will reveal a secret x_r (which is NOT the node privkey of R).
> > >
> > > What happens really here is that each hop sets up a PTLC.
> > > The sender is responsible for ensuring that the F->R PTLC is equal to
> x_r * G, that E->F is equal to (x_f + x_r) * G, that D->E is equal to (x_e
> + x_f + x_r) * G, and so on.
> > > However, the sender knows only (x_r * G) without knowing x_r, thus it
> never is able to completely control the secret at every point -- the
> receiver knows the other secret as well.
> > >
> > > That is the entire crux of the argument --- *both* sender and receiver
> control the secrets anyway, so it is not controlled by a single entity, at
> least for non-self-payments.
> > >
> > > > 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?).
> > >
> > > Griefing attacks are only possible by not claiming or forwarding the
> attack.
> > > If S and B "collude" to perform a grief, then either B never forwards
> to C, in which case there is no possible way to attack, or C receives it
> and claims it but B does not claim it, in which case B paid out money and
> is now idiotically refusing to claim money.
> > >
> > > Grief attacks are attacks by payers and payees on intermediate nodes
> (S and R attacking A,B,C,D,E,F), and in that case the entire payment secret
> would be known by both S and R anyway.
> > >
> > > So S and B cannot cooperate to perform a griefing attack on the path.
> > >
> > > Regards,
> > > ZmnSCPxj
> > >
> > > >
> > > > 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.
> >
> > --
> > Yours sincerely,
> > Subhra Mazumdar.
>
>
>
--
Yours sincerely,
Subhra Mazumdar.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20200402/0c9a9d1b/attachment-0001.html>;