Subhra Mazumdar [ARCHIVE] on Nostr: 📅 Original date posted:2020-04-02 📝 Original message: Thank you for the ...
📅 Original date posted:2020-04-02
📝 Original message:
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.
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20200402/8ca72e42/attachment-0001.html>;
📝 Original message:
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.
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20200402/8ca72e42/attachment-0001.html>;