Introduce ReceiveAuthKey verification for Blinded Payment Paths #4126
Conversation
|
I've assigned @jkczyz as a reviewer! |
shaavan
force-pushed
the
aad-payment
branch
from
69c57f9 to
359267e
Compare
shaavan
force-pushed
the
aad-payment
branch
from
359267e to
13c4041
Compare
Codecov Report❌ Patch coverage is Additional details and impacted files@@ Coverage Diff @@
## main #4126 +/- ##
==========================================
+ Coverage 88.57% 88.63% +0.06%
==========================================
Files 179 180 +1
Lines 134374 135169 +795
Branches 134374 135169 +795
==========================================
+ Hits 119016 119808 +792
+ Misses 12604 12597 -7
- Partials 2754 2764 +10
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
|
🔔 1st Reminder Hey @jkczyz! This PR has been waiting for your review. |
|
🔔 2nd Reminder Hey @jkczyz! This PR has been waiting for your review. |
|
🔔 3rd Reminder Hey @jkczyz! This PR has been waiting for your review. |
|
🔔 4th Reminder Hey @jkczyz! This PR has been waiting for your review. |
|
🔔 5th Reminder Hey @jkczyz! This PR has been waiting for your review. |
Extends the work started in [PR#3917](lightningdevkit#3917) by adding ReceiveAuthKey-based verification for Blinded Payment Paths. This reduces space previously taken by individual ReceiveTlvs and aligns the verification logic with that used for Blinded Message Paths.
Now that we have introduced an alternate mechanism for authentication in the codebase, we can safely remove the now redundant (hmac, nonce) fields from the Payment ReceiveTlvs's while maintaining the security of the onion messages.
|
🔔 6th Reminder Hey @jkczyz! This PR has been waiting for your review. |
|
🔔 7th Reminder Hey @jkczyz! This PR has been waiting for your review. |
|
🔔 8th Reminder Hey @jkczyz! This PR has been waiting for your review. |
|
🔔 9th Reminder Hey @jkczyz! This PR has been waiting for your review. |
|
🔔 10th Reminder Hey @jkczyz! This PR has been waiting for your review. |
|
🔔 11th Reminder Hey @jkczyz! This PR has been waiting for your review. |
|
🔔 12th Reminder Hey @jkczyz! This PR has been waiting for your review. |
|
🔔 13th Reminder Hey @jkczyz! This PR has been waiting for your review. |
|
🔔 14th Reminder Hey @jkczyz! This PR has been waiting for your review. |
| let node_chanmgr = create_node_chanmgrs(1, &node_cfg, &[None]); | ||
| let node = create_network(1, &node_cfg, &node_chanmgr); | ||
| let sender_intended_amt_msat = 100; | ||
| let logger = TestLogger::new(); |
There was a problem hiding this comment.
You should be able to use the logger from Node.
| PeerOffline, | ||
| /// The HTLC was failed because the channel balance was overdrawn. | ||
| ChannelBalanceOverdrawn, | ||
| /// The payload we received was not authenticated by our node. |
| /// The payload we received was not authenticated by our node. | ||
| /// | ||
| /// This can occur if we constructed an invalid [`BlindedPaymentPath`] | ||
| /// for our counterparty to send a payment over. |
There was a problem hiding this comment.
"counterparty" implies our immediate peer, but this is more likely from a node not directly connected to us.
| /// This can occur if we constructed an invalid [`BlindedPaymentPath`] | ||
| /// for our counterparty to send a payment over. |
There was a problem hiding this comment.
Isn't it more likely a malicious node tried to de-anonymize us but wasn't able to form a blinded path that we'd authenticate any payment over?
| } | ||
| } | ||
|
|
||
| // Note: Authentication TLV field was removed in LDK v0.2 following the |
There was a problem hiding this comment.
May need to bump this to 0.3 unless @TheBlueMatt wants to include it in 0.2.
| // `BlindedPaymentPaths`s. Because we do not support receiving to those | ||
| // contexts anymore (they will fail the `ReceiveAuthKey`-based | ||
| // authentication checks), we can reuse those fields here. |
There was a problem hiding this comment.
I don't follow the part about re-use.
|
|
||
| // HMAC input for `ReceiveTlvs`. The HMAC is used in `blinded_path::payment::PaymentContext`. | ||
| const PAYMENT_TLVS_HMAC_INPUT: &[u8; 16] = &[8; 16]; | ||
| // const PAYMENT_TLVS_HMAC_INPUT: &[u8; 16] = &[8; 16]; |
There was a problem hiding this comment.
Let's remove instead of commenting out.
|
👋 The first review has been submitted! Do you think this PR is ready for a second reviewer? If so, click here to assign a second reviewer. |
3 participants
Building on the goals set forth in #3917, this PR introduces ReceiveAuthKey-based verification for Blinded Payment Paths.
Key Outcomes
ReceiveTlvsare noticeably reduced in size, making blinded paths lighter.Follow-Up Preparation
This PR also lays the groundwork for introducing dummy payment hops in a follow-up PR.
By minimizing per-hop authentication data, we keep dummy hops compact — preserving overall path size and ensuring that forward and dummy TLVs are padded to the same length, improving hop indistinguishability and privacy.