From subhra.mazumdar1993 at gmail.com Thu Apr 2 17:42:06 2020 From: subhra.mazumdar1993 at gmail.com (Subhra Mazumdar) Date: Thu, 2 Apr 2020 23:12:06 +0530 Subject: [Lightning-dev] Blind paths revisited In-Reply-To: <4qExZ9p0lUXQSmksklLrBXmGVhHn5cK7OziBvzcBz70C0JPd9BrVXFmZYMIblTQgpk5aY3vv9aEAOC-g-T6vCdUlIXB28ZDwh4o21NCH4RI=@protonmail.com> References: <87k13txds8.fsf@rustcorp.com.au> <87a74nyfmy.fsf@rustcorp.com.au> <4qExZ9p0lUXQSmksklLrBXmGVhHn5cK7OziBvzcBz70C0JPd9BrVXFmZYMIblTQgpk5aY3vv9aEAOC-g-T6vCdUlIXB28ZDwh4o21NCH4RI=@protonmail.com> Message-ID: Hi ZmnSCPxj, Thank you for the clarification.I got your point. On Thu, Apr 2, 2020 at 1:35 PM ZmnSCPxj 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 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 > 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: