Improve privacy for Blinded Message Paths using Dummy Hops #3726
Conversation
|
👋 Thanks for assigning @valentinewallace as a reviewer! |
|
|
||
| match next_hop { | ||
| NextMessageHop::NodeId(ref id) if id == &our_node_id => { | ||
| peel_onion_message(&onion_message, secp_ctx, node_signer, logger, custom_handler) |
There was a problem hiding this comment.
Is there any risk somehow of infinite recursion?
There was a problem hiding this comment.
Thanks so much for pointing this out!
I took some time to sit with it, and here’s what I gathered —
Since blinded paths have a fixed upper limit on their size (as the number of hop_payloads is bounded), there can only be a finite number of ForwardTlvs. And at each step, we’re peeling off a layer and moving forward—not looping back—so the processing always progresses toward completion.
Given that, I believe there’s no risk of infinite recursion in this setup.
That said, if there’s a subtle case I’ve missed or something you see differently, I’d really appreciate hearing your thoughts. Thanks again!
There was a problem hiding this comment.
I hadn't spotted a specific problem, was just curious how certain it is that infinite recursion cannot happen. If the explanation isn't straight-forward, I'd add it as a comment to the code. And refer to point where the limitation is, something with new_packet_bytes I think?
There was a problem hiding this comment.
It can't be infinite, but with an extra-long onion message ISTM it could still be a lot of processing time. If someone created a blinded path terminating at us with a bunch of dummy hops and we only find out that it's an inauthentic path when we get to the final layer, seems like that might be an issue.
@shaavan would it be possible to explore adding a new ControlTlvs::Dummy variant that contains an HMAC and nonce, similar to how we authenticate blinded receive payloads elsewhere? And authenticate those fields before peeling the onion further?
There was a problem hiding this comment.
Sure! Let me give it a shot! 🚀
| ) -> Result<Vec<BlindedHop>, secp256k1::Error> { | ||
| let pks = intermediate_nodes | ||
| .iter() | ||
| .map(|node| node.node_id) | ||
| .chain((0..dummy_hops_count).map(|_| recipient_node_id)) |
There was a problem hiding this comment.
I looked up the bolt spec and read
"MAY add additional "dummy" hops at the end of the path (which it will ignore on receipt) to obscure the path length."
What does ignore mean exactly? It seems in the next commit that it means to keep peeling? Using the recipient node id for all the dummy hops isn't really described in the bolt I think. Maybe mistaking.
Also a mention of padding is made:
"The padding field can be used to ensure that all encrypted_recipient_data have the same length. It's particularly useful when adding dummy hops at the end of a blinded route, to prevent the sender from figuring out which node is the final recipient"
Not sure if that is done now too?
There was a problem hiding this comment.
What does “ignore” mean exactly? It seems in the next commit that it means to keep peeling? Using the recipient node id for all the dummy hops isn't really described in the bolt I think. Maybe mistaking.
The thinking behind this approach was that if dummy hops were added after the ReceiveTlvs, it could open up timing-based attacks—where an attacker might estimate the position of the actual recipient based on how quickly a response is returned.
To avoid that, I added the dummy hops just before the final node. This way, even after receiving a dummy hop (with ForwardTlvs directed to self), the node still has to keep peeling until it reaches the actual ReceiveTlvs. This helps make response timing more uniform and avoids leaking information about path length.
Also a mention of padding is made
Yes! In PR #3177, we added support for padding in both BlindedMessagePaths and BlindedPaymentPaths, ensuring all payloads are a multiple of PADDING_ROUND_OFF.
Since the MESSAGE_PADDING_ROUND_OFF buffer is large enough, every payload—whether it's a ForwardTlvs, dummy hop, or ReceiveTlvs—ends up with the same total length. This helps prevent the sender from inferring the number of hops based on packet size.
I've also updated the padding tests to use new_with_dummy_hops, so we make sure even dummy hops are padded the same way as real ones.
Thanks so much again for the super helpful feedback!
There was a problem hiding this comment.
To avoid that, I added the dummy hops just before the final node.
If this is strictly better, it could be worth a PR to the bolt spec? At the minimum it might get you some feedback on this line of thinking.
I am not sure if the timing attack is avoided though, and worth the extra complexity. Peeling seems to be so much faster than an actual hop with network latency etc. Some random delay might be more effective?
There was a problem hiding this comment.
The code also still works for blinded paths where dummy hops are added after the ReceiveTlvs right? Just making sure.
There was a problem hiding this comment.
The code also still works for blinded paths where dummy hops are added after the ReceiveTlvs right? Just making sure.
There shouldn't be a need to support that because we only support receiving to blinded paths that we create.
There was a problem hiding this comment.
The timing attack does seem like a potential issue though. Not sure how to address that without adding some kind of ProcessPendingHtlcsForwardable event for onion messages, which seems like overkill. I think we can maybe document it on the issue and push to follow-up? @TheBlueMatt do you have any thoughts on how to simulate a fake onion message forward when processing dummy hops?
Adds a new constructor for blinded paths that allows specifying the number of dummy hops. This enables users to insert arbitrary hops before the real destination, enhancing privacy by making it harder to infer the sender–receiver distance or identify the final destination. Lays the groundwork for future use of dummy hops in blinded path construction. Co-authored-by: valentinewallace <[email protected]>
Adds support for identifying and handling dummy hops during the onion message peeling process. Ensures that Dummy Forward TLVs are correctly recognized and interpreted as non-routing hops. Co-authored-by: valentinewallace <[email protected]>
|
Updated from pr3728.01 to pr3728.02 (diff): Changes:
|
|
🔔 1st Reminder Hey @valentinewallace! This PR has been waiting for your review. |
|
🔔 2nd Reminder Hey @valentinewallace! This PR has been waiting for your review. |
| ) -> Result<Vec<BlindedHop>, secp256k1::Error> { | ||
| let pks = intermediate_nodes | ||
| .iter() | ||
| .map(|node| node.node_id) | ||
| .chain((0..dummy_hops_count).map(|_| recipient_node_id)) |
There was a problem hiding this comment.
The timing attack does seem like a potential issue though. Not sure how to address that without adding some kind of ProcessPendingHtlcsForwardable event for onion messages, which seems like overkill. I think we can maybe document it on the issue and push to follow-up? @TheBlueMatt do you have any thoughts on how to simulate a fake onion message forward when processing dummy hops?
Applies dummy hops by default when constructing blinded paths via `DefaultMessageRouter`, enhancing privacy by obscuring the true path length. Uses a predefined `DUMMY_HOPS_COUNT` to apply dummy hops consistently without requiring explicit user input.
Introduces a test to verify correct handling of dummy hops in constructed blinded paths. Ensures that the added dummy hops are properly included and do not interfere with the real path. Co-authored-by: valentinewallace <[email protected]>
|
Updated from pr3728.02 to pr3728.03 (diff): Changes:
|
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #3726 +/- ##
==========================================
+ Coverage 89.18% 90.85% +1.66%
==========================================
Files 155 156 +1
Lines 120941 139897 +18956
Branches 120941 139897 +18956
==========================================
+ Hits 107863 127104 +19241
+ Misses 10438 10243 -195
+ Partials 2640 2550 -90 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
Resolves #3252
This PR improves privacy in blinded path construction by introducing support for dummy hops.
While blinded paths obscure node identities, they still might reveal the number of hops—potentially leaking information about the distance between sender and receiver.
To mitigate this, we now prepend dummy hops for
BlindedMessagePaths, that serve no routing purpose but act as decoys. This makes it significantly harder to estimate the true position of the destination node based on path length.