Comments (7)
Yeah the spec just refers to the origin node in this part:
The origin node:
once the return message has been decrypted:
SHOULD store a copy of the message.
SHOULD continue decrypting, until the loop has been repeated 20 times.
SHOULD use constant ammag and um keys to obfuscate the route length.
https://github.com/lightning/bolts/blob/master/04-onion-routing.md#returning-errors
So I think we can remove it.
from bolts.
I believe that's just a leftover that we should remove from the spec, feel free to open a PR! We should loop until we've exhausted the shared secrets (which matches the number of hops we actually used for the payment path), not until a specific hard-coded value.
from bolts.
I believe that's just a leftover that we should remove from the spec, feel free to open a PR! We should loop until we've exhausted the shared secrets (which matches the number of hops we actually used for the payment path), not until a specific hard-coded value.
Isn't the fixed number of decryptions needed to prevent any intermediate nodes from learning the source/destination via timing? If so, it would make more sense to increase the hard-coded value to 27 instead of removing it.
from bolts.
Maybe we're not talking about the same steps in the onion process. I thought @ziggie1984 meant what is done by the sender of a payment when it receives an update_fail_htlc
message and tries to decrypt the error contained in that message. In that case I don't think there is any timing-related attacks that applies?
from bolts.
I am also confused about the last part:
SHOULD use constant ammag and um keys to obfuscate the route length.
I am not sure what is meant by obfuscate, because the origin node only cares about de-obfuscating, the ammag and um keys are locked in at this point for the routing hops (defined when building the route?). So not sure why this is important. I thought the erring nodes decides the size of the failure message
and all the following nodes should keep the size constant?
And not sure about the first requirement as well:
SHOULD store a copy of the message.
Should we really require this, it's up to the sender to decide whether he wants to keep the data or not, I think relay protection is not really relevant for the Erring Messages?
from bolts.
I believe @morehouse is right, those 3 requirements were added to be somewhat "constant-time" on the sender side when decrypting an update_fail_htlc
error. What those requirements suggest is that after correctly decrypting the error message after N steps (where N is the position of the erring node in the route) you should keep doing dummy decryption steps to make it look like the error came from the 20th node in the route. Since the route is usually smaller than 20, you don't have ammag
and um
keys for the fake hops, so the requirements suggest using dummy constant ones.
I believe all of this is useless (timing leaks are dominated by network latency in retries), so we have not implemented this in eclair and we instead stop as soon as we get the decrypted message. Those requirements are only a SHOULD
, they aren't a MUST
, so it's perfectly ok to ignore them.
from bolts.
Ok now I understand, it specifically relates to the case where we would try the same payment via a different route and if we do not account for timing we would kind of reveal to the nodes in the path at which position they are probably in.
So I think 20 seems like good enough. I think it probably makes sense to add more context (Rationale) to this part of the requirement I can add a PR describing it if we want that or even increase the hop size to 27?
from bolts.
Related Issues (20)
- Lightning Specification Meeting 2024/02/12 HOT 1
- [feature] Allow the recovering of (outgoing) HTLCs in a DLP case. HOT 3
- Lightning Specification Meeting 2024/02/26 HOT 4
- to_self_delay cannot be updated after opening a channel HOT 3
- Lightning Specification Meeting 2024/03/11 HOT 1
- Lightning Specification Meeting 2024/03/25 HOT 2
- Lightning Specification Meeting 2024/04/08 HOT 3
- Lightning Specification Meeting 2024/04/22 HOT 10
- BOLT-4: Decrypt onion using b_i or k_i HOT 2
- Lightning Specification Meeting 2024/05/06 HOT 4
- Lightning Specification Meeting 2024/05/20 HOT 3
- Add support for bundled payments in BOLT12 HOT 1
- Lightning Specification Meeting 2024/06/03 HOT 2
- BOLT-11: add optional feature bit to indicate delayed settlement of invoice HOT 7
- Lightning Dev Summit Topics HOT 9
- Lightning Specification Meeting 2024/06/17 HOT 1
- Discussion: some confusion re blinded path `max_cltv` HOT 2
- Lightning Specification Meeting 2024/07/01 HOT 1
- Lightning Specification Meeting 2024/07/15 HOT 1
- missing bolt11 example where `n` field must be verified by reader
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from bolts.