Re: [Lightning-dev] Reason for having HMACs in Sphinx
Corné Plooy via Lightning-dev writes: > For instance, the attacking intermediate node might guess that the next > node in the route is the final node; it can test this by completely > replacing the onion packet it sends to the next node with a self-written > onion packet that has the next hop as final node, with the same amount > and payment hash as instructed by the incoming payment. If that > succeeds, it has learned that the next node is indeed the final node > (and nobody gets to know about the attack) This is always true, regardless of construction, with our current scheme. > ; if that fails, it might > retry the payment with the original onion packet. In that case, it > learned that the next node is *not* the final node. In this case, the > attack is detectable by the next node though: it first receives an > incoming payment with a payment hash it doesn't recognize, and then it > receives a payment forwarding request with the same payment hash. True. Note that we go as far as preventing forwarding of the same onion (for traffic analysis), but we don't block this more obvious attack. > I think we could stop this type of attack by including some kind of > shared secret in the onion message to the final node: > > * Payee generates shared secret and passes this to payer, as part of the > invoice > > * Payer includes shared secret in the per hop data to payee > > * On receiving the incoming message, payee checks whether the received > shared secret corresponds to the generated one. If this is not the case, > behave in exactly the same way as when the payment hash is unrecognized > (including timing, to prevent timing side-channel attacks). This would indeed be an incremental improvement: I generally prefer not to rely on the privacy of the invoice delivery, but this certainly makes it no worse. > The shared secret doesn't need to be very large: the number of attempts > per second (to guess the shared secret) is limited by network latency, > bandwidth and maybe some artificial rate limiting. If an attacker can do > 100 attempts per second, then a 32-bit shared secret will take (on > average) 2^31 / (100*3600*24) = 248 days to crack, for a single guess of > which node is the final node. In the mean time, people will have noticed > the ongoing attack and will have taken countermeasures. Besides, the > transaction lock time will likely have expired in the mean time as well. We could really just use the last 4 bytes of the signature, AFAICT. Cheers, Rusty. ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Base AMP
Except we have invoices with no specified amount (payer dictates how much to pay). Which is why we need to send the total amount to the payee as part of the onion final hop, for the case the invoice has no specified amount. Regards, ZmnSCPxj Sent with [ProtonMail](https://protonmail.com) Secure Email. ‐‐‐ Original Message ‐‐‐ On Tuesday, December 4, 2018 7:40 PM, Christian Decker wrote: > Which brings us back to the initial proposal that just signals the awareness > of a temporary underpayment with the single "more is coming"-bit. > > On Sun, Dec 2, 2018 at 11:49 PM Rusty Russell wrote: > >> ZmnSCPxj writes: >>> But what if 2 of those paths fail? >>> It would be better to merge them into a single payment along the expensive >>> 4th path. >>> However, the remaining succeeding path has already given `numpaths`=3. >>> >>> Using `numpaths` overcommits to what you will do in the future, and is >>> unnecessary anyway. >>> The payee is interested in the total value, not the details of the split. >> >> Excellent point. >> >> Thanks, >> Rusty. >> ___ >> Lightning-dev mailing list >> Lightning-dev@lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Reason for having HMACs in Sphinx
Good morning CJP, > > > I think we could stop this type of attack by including some kind of > > > shared secret in the onion message to the final node: > > > I think we get this "for free" if we switch to path decorrelation and > > > points+privkeys instead of hashes+preimages. > > > > Path decorrelation means that each hop is given a random point, to be added > > to the next SS "HTLC". > > The final node needs to be given the total of the scalars of each hop > > random point along the route, most likely within the last hop of the onion. > > The final node also cannot differentiate between an incorrect total for > > this scalar, or an incorrect "invoice hash"/invoice point. > > Hence, some intermediate node along the way cannot guess this, and the > > final node will give the same error, i.e. "invoice point not found". > > That might indeed stop an attacker from testing 2nd-degree, 3rd-degree > etc. neighbors, making the attack much less versatile. However, for his > direct neighbor in the route, the attacker does learn the point to be > used in that hop. Therefore I think the attacker can still test whether > or not the next node is the final hop. I believe not? For example if the route is A -> B -> C: 1. C creates an invoice secret i, and the invoice point I = i * G, and gives I to node A. 2. A creates two secrets k[a] and k[b], and total sum k = k[a] + k[b]. 3. A creates points K[A] = k[a] * G and K[B] = k[b] * G. 4. A creates an onion as below: * layer 0 (to B): decorrelation_secret = k[b] * layer 1 (to B): total_decorrelation_secrets = k = k[a] + k[b] 5. A offers the HTLC to B, for the secret to the point (I + K[A]). 6. B offers the HTLC to C, for the secret to the point ((I + K[A]) + K[B]). The total_decorrelation_secrets serves as the payer-generated shared secret between payer and payee. B cannot learn this, and thus cannot fake its own secret. Even if it instead offers ((I + K[A]) + k[z] * G) for a new secret k[z], it cannot know how to change total_decorrelation_secrets from k[a] + k[b] to k[a] + k[z] instead. Regards, ZmnSCPxj ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Colored coins or non-fungible tokens
Dear Joao, there are the people from BHB Networks (in Itally) working on colored coins for Bitcoin and Lightning. The main contributor seems to be Alekos Filini. As far as I understand there is quite some progress. You can find more information in their spec repo at: https://github.com/rgb-org/spec The 4th. md file in that repo is about the lightning network (not sure if this is still up to date with the current implementation that Alekos is also working on.) I believe Alekos has talked about this at the third lightning hackday in Berlin and on the LightningHackdayNYC both talks have been recorded and can be found on youtube. Therefor I suggest to talk to Alekos (ccd) directly. I hope that helps. best Rene On Tue, Dec 4, 2018 at 2:29 PM Joao Joyce wrote: > Hi list, > > Thank you all for the great work. LN is looking amazing! > > I was wondering if there is any discussion about exchanging colored-coins > or non-fungible tokens through the LN. > Or even issuance, which I'm not seeing how it would be possible, but > recognise that this space is full of surprises. > > That would be a great addition to LN and it would enable new use-cases. > > Thank you all for the great work. > ___ > Lightning-dev mailing list > Lightning-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev > -- https://www.rene-pickhardt.de Skype: rene.pickhardt mobile: +49 (0)176 5762 3618 ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
[Lightning-dev] Colored coins or non-fungible tokens
Hi list, Thank you all for the great work. LN is looking amazing! I was wondering if there is any discussion about exchanging colored-coins or non-fungible tokens through the LN. Or even issuance, which I'm not seeing how it would be possible, but recognise that this space is full of surprises. That would be a great addition to LN and it would enable new use-cases. Thank you all for the great work. ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Reason for having HMACs in Sphinx
>> I think we could stop this type of attack by including some kind of >> shared secret in the onion message to the final node: > I think we get this "for free" if we switch to path decorrelation and > points+privkeys instead of hashes+preimages. > > Path decorrelation means that each hop is given a random point, to be added > to the next SS "HTLC". > The final node needs to be given the total of the scalars of each hop random > point along the route, most likely within the last hop of the onion. > The final node also cannot differentiate between an incorrect total for this > scalar, or an incorrect "invoice hash"/invoice point. > > Hence, some intermediate node along the way cannot guess this, and the final > node will give the same error, i.e. "invoice point not found". > > That might indeed stop an attacker from testing 2nd-degree, 3rd-degree etc. neighbors, making the attack much less versatile. However, for his direct neighbor in the route, the attacker does learn the point to be used in that hop. Therefore I think the attacker can still test whether or not the next node is the final hop. CJP ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Reason for having HMACs in Sphinx
Thanks Christian, that makes sense. Unfortunately it's not very clear from the BOLT, at least not for me. Now that I think of this type of attack: *in general* the HMAC prevents this kind of attack, but isn't the attack still possible in certain specific cases? For instance, the attacking intermediate node might guess that the next node in the route is the final node; it can test this by completely replacing the onion packet it sends to the next node with a self-written onion packet that has the next hop as final node, with the same amount and payment hash as instructed by the incoming payment. If that succeeds, it has learned that the next node is indeed the final node (and nobody gets to know about the attack); if that fails, it might retry the payment with the original onion packet. In that case, it learned that the next node is *not* the final node. In this case, the attack is detectable by the next node though: it first receives an incoming payment with a payment hash it doesn't recognize, and then it receives a payment forwarding request with the same payment hash. Given that the attacker has good knowledge of the shape of the Lightning network, this type of attack can be generalized to test whether a certain second-degree neighbor, third-degree neighbor etc. is the final node; it scales pretty badly with increasing network distance though. An additional advantage for the attacker is that this gives plausible deniability: if the attack becomes visible, the attacker can always claim it wasn't him, but some node upstream in the route. A practical difficulty for the attacker might be that the exact amount forwarded in further-away hops is unknown, but it's probably not that difficult to guess. I think we could stop this type of attack by including some kind of shared secret in the onion message to the final node: * Payee generates shared secret and passes this to payer, as part of the invoice * Payer includes shared secret in the per hop data to payee * On receiving the incoming message, payee checks whether the received shared secret corresponds to the generated one. If this is not the case, behave in exactly the same way as when the payment hash is unrecognized (including timing, to prevent timing side-channel attacks). If this shared secret is encrypted like the rest of the per hop data, the attacker can't learn the shared secret, and can't include it in his own replacement onion. He can't copy-paste the encrypted shared secret from the original onion either, since he has to use his own, different ephemeral key in his own onion. With this protocol in place, a final node can no longer be distinguished from a non-final node with this attack. The shared secret doesn't need to be very large: the number of attempts per second (to guess the shared secret) is limited by network latency, bandwidth and maybe some artificial rate limiting. If an attacker can do 100 attempts per second, then a 32-bit shared secret will take (on average) 2^31 / (100*3600*24) = 248 days to crack, for a single guess of which node is the final node. In the mean time, people will have noticed the ongoing attack and will have taken countermeasures. Besides, the transaction lock time will likely have expired in the mean time as well. CJP On 29-11-18 18:13, Christian Decker wrote: > Hi Corne, > > the HMACs are necessary in order to make sure that a hop cannot modify > the packet before forwarding, and the next node not detecting that > modification. > > One potential attack that could facilitate is that an attacker could > learn the path length by messing with different per-hop payloads: set > n=0 the attacker flips bits in the nth per-hop payload, and forwards > it. If the next node doesn't return an error it was the final recipient, > if if returns an error, increment n and flip bits in the (n+1)th per-hop > payload, until no error is returned. Congratulation you just learned the > path length after you. The same can probably be done with the error > packet, meaning you can learn the exact position in the route. Add to > that the information you already know about the network (cltv_deltas, > amounts, fees, ...) and you can probably detect sender and recipient. > > Adding HMACs solves this by ensuring that the next hop will return an > error if anything was changed, i.e., removing the leak about which node > would have failed the route. > > Cheers, > Christian ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
