ln: double encrypt errors received from downstream failures
What the developer wrote
Authored by Carla Kirk-Cohen
ln: double encrypt errors received from downstream failures
If we're a trampoline node and received an error from downstream that
we can't fully decrypt, we want to double-wrap it for the original
sender. Previously not implemented because we'd only focused on
receives, where there's no possibility of a downstream error.
While proper error handling will be added in a followup, we add the
bare minimum required here for testing.
What changed, and why it matters
This commit adds missing encryption wrapping for error messages in the Lightning Dev Kit when acting as a 'trampoline' forwarding node. Previously, if a downstream node returned an error that the trampoline could not fully decrypt, the error would not be properly re-wrapped for the original sender. The change ensures the error is encrypted with both the trampoline's own shared secret and the incoming shared secret, so it can travel back to the payer correctly. The commit message explicitly says this is the 'bare minimum' and that proper error handling will follow later.
Treat this as a functional correctness fix for trampoline error propagation rather than an active vulnerability. Review the planned followup error-handling work, add tests covering downstream trampoline failures, and monitor for any related disclosures about trampoline error privacy or routing failures.
Security signals we found
Missing cryptographic wrapping of failure packets in trampoline forwarding path
Potential information leakage or unrecoverable error propagation for trampoline payments
Commit describes the change as bare-minimum with followup proper error handling planned
Evidence from the diff
In lightning/src/ln/onion_utils.rs, inside HTLCFailReason::build_onion_hop_data or a related failure-packet construction path, the code now checks for a secondary_shared_secret (the secret shared with the downstream trampoline hop). If present, it first processes and encrypts the failure packet with that secondary secret, then proceeds with the existing processing/encryption using the incoming_packet_shared_secret. This implements ‘double encryption’ of downstream errors so the original sender can unwrap them. The commit message notes this was previously unimplemented because the codebase had focused on receive-side trampoline where no downstream error exists.
Changed components
lightning/src/ln/onion_utils.rsTrampoline routing / forwarding error handlingHTLC failure onion packet constructionInspect captured patch +4 / −0
diff --git a/lightning/src/ln/onion_utils.rs b/lightning/src/ln/onion_utils.rs
index d4ee3d3..4be803f 100644
--- a/lightning/src/ln/onion_utils.rs
+++ b/lightning/src/ln/onion_utils.rs
@@ -2126,6 +2126,10 @@ impl HTLCFailReason {
let mut err = err.clone();
let hold_time = hold_time.unwrap_or(0);
+ if let Some(secondary_shared_secret) = secondary_shared_secret {
+ process_failure_packet(&mut err, secondary_shared_secret, hold_time);
+ crypt_failure_packet(secondary_shared_secret, &mut err);
+ }
process_failure_packet(&mut err, incoming_packet_shared_secret, hold_time);
crypt_failure_packet(incoming_packet_shared_secret, &mut err);
Why this scored 34/100
Community notes
Notes can correct, qualify, or add evidence to the AI analysis. Every note shown here has been validated by a human moderator.
The AI analysis stands alone for now. Submit a note if you can add evidence or important context.