Re: [Lightning-dev] Covert channel recovery with Oblivious Signatures
Hi Dave, Thanks for taking a read. You brought up really good points that need addressing. This is really cool! However, I don't understand why it's needed. Your > goal seems to be for the sender to provide the commitment transaction > and signatures before he learns whether the receiver actually needs > them. That's just as easily accomplished by sending the data upfront in > plain text. > To be clear: The goal is to offer a cooperative settlement transaction up front to the (possibly) recovering party -- *not a commitment transaction*. Note we cannot send a cooperative settlement tx up front for each connection since they are not revocable -- the channel is over once it has been received. I admit I didn't properly consider just sending commitment transactions over. This is probably because it exposes the recovering party to the punishment mechanism and in my most recent line of research you *really* don't want to do this. The idea I'm working with in revocable signature based channels [1] is to make the node lose its static secret key if it posts a revoked commitment tx. This means they could lose ALL funds from ALL their channels with ALL their peers if they ever broadcast a single revoked commitment transaction. This would be a very bad thing to happen while you're trying to recover funds. I agree with your core point that in LN as it exists today the security assumption of both methods is that the adversary will be unable to distinguish a connection attempt after data loss from an ordinary one. If they can reliably do this then both methods can lead to loss of funds so why bother with the wonky crypto? I think there is a subtle reason why oblivious settlement signatures are still preferable: it is difficult to provide a coherent UX for recovery when just sending YOLO commitment transactions. It would be best if the recovery UX was "hey user I've found 0.367 Bitcoin across these three channels would you like to recover them?". The user can then accept this or cancel the recovery process and go through some extra trouble to recover their data (in practice, data is often not completely lost but recoverable with some effort). This is how it could work using the oblivious settlement txs I proposed. Using YOLO commitment transactions this becomes "hey user I've found 0.523 Bitcoin across three channels" which may actually be more than you are owed to entice you to shoot yourself in the foot. Even if it's exactly what you are owed, when you confirm the recovery your next message might be "nd it's gone" because one of the commit txs was revoked. It seems difficult to recommend YOLO commitment transactions becoming the standard way to recover funds. It could be preferable to the current system but even that is up for debate I guess. I feel like I can recommend oblivious settlements because (i) it's covert (like YOLO commitments txs unlike current system) and (ii) it's "what you see is what you get" -- you are guaranteed to recover the funds that you are presented with once you finally trigger the recovery. Although I do think oblivious settlement txs is a good idea I am working on yet *another* recovery idea for doing peer provided encrypted backup and full channel restoration in a way that provides another guarantee: If the peer sends you an outdated encrypted backup (perhaps in the hope that it has a revoked commitment tx in it) -- you can punish them immediately upon receiving the backup (if you haven't actually had data loss). Unfortunately, It looks like this will use more heavy cryptographic primitives. I think the challenge in either protocol above is deciding which peer > goes first, because whoever sends the commitment transaction reveals > what they think the current state is. Any node that refuses to go first > can then be suspected of having lost data. BOLT2 > option_static_remotekey has this same problem, which is reasonably > mitigated IMO by LN's penalty mechanism forcing any would-be thief to > risk their own funds; this doesn't work for basic eltoo, though. > What is the story with option_static_remotekey? I am interested to know how the negotiation of that option has a security issue but I don't see how it could. [1]: https://github.com/LLFourn/witness-asymmetric-channel Cheers, LL ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Covert channel recovery with Oblivious Signatures
On Fri, Dec 11, 2020 at 01:02:04PM +1100, Lloyd Fournier wrote: > If c = 1 (i.e. the node is fine and it wants to continue the channel) then > it checks `encrypted_signature_verify(X, settlement_tx, Y)`. If it passes > it sends the commitment blinding y back to prove that it doesn't have the > signature (i.e. prove c = 1). If verification fails then the node is > malicious and it fails the channel. This is really cool! However, I don't understand why it's needed. Your goal seems to be for the sender to provide the commitment transaction and signatures before he learns whether the receiver actually needs them. That's just as easily accomplished by sending the data upfront in plain text. For example, it seems to me that both of the following protocols provide identical utility: 1. On every reconnection, request the plain text unsigned commitment transaction, send a pedersen commitment, and receive the encrypted signature(s). If c=1, verify the encrypted signature(s) and (on success) send the blinding factor or (on failure) fail the channel and ban the peer. If c=0, decrypt the signature(s), apply them to the commitment transaction, and broadcast. 2. On every reconnection, request the plain text unsigned commitment transaction with all of its signatures, also in plain text. If our database is intact, verify the commitment transaction and its signatures are valid and (on success) continue or (on failure) fail and ban. If we lost data, broadcast the commitment transaction. Unless I'm forgetting something, there's no reason a node shouldn't send its latest commitment transaction to its counterparty in plain text (over the regular BOLT8 P2P encrypted and authenticated link). I think the challenge in either protocol above is deciding which peer goes first, because whoever sends the commitment transaction reveals what they think the current state is. Any node that refuses to go first can then be suspected of having lost data. BOLT2 option_static_remotekey has this same problem, which is reasonably mitigated IMO by LN's penalty mechanism forcing any would-be thief to risk their own funds; this doesn't work for basic eltoo, though. -Dave signature.asc Description: PGP signature ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
