AI-generated analysisPublished automatically and not human-verified. Validated context appears in community notes below.
← Watch feed
Low 35 Bitcoin

Introduce ReceiveAuthKey-based verification in Blinded Payment Paths

Public commit record

What the developer wrote

Authored by shaavan

91/100 · Strong
Introduce ReceiveAuthKey-based verification in Blinded Payment Paths

Extends the work started in
[PR#3917](https://github.com/lightningdevkit/rust-lightning/pull/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.
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Mentions testing or verification✓ Links an issue, advisory, or supporting reference
The short version

What changed, and why it matters

This commit changes how hidden (blinded) Lightning payment paths are created and checked. It adds a new 'receive authentication key' used when encrypting the final hop's details, and it makes the receiving node verify that the final hop was encrypted with that key. This is a defensive hardening change that reduces the data sent in payment paths and makes the verification logic consistent with another similar feature (blinded message paths).

Recommended action

Treat as a hardening/correctness improvement rather than an active vulnerability fix. Review the ChaChaDualPolyReadAdapter implementation separately to confirm the AAD handling and key derivation are sound, and ensure all downstream Router implementations have been updated to supply the receive auth key.

Security signals we found

01

New cryptographic authentication key (ReceiveAuthKey) added to blinded payment path construction and verification

02

Final receive hop now requires the auth-key AAD; forward hops must not use it

03

ChaChaPolyReadAdapter replaced by ChaChaDualPolyReadAdapter with dual-key material (rho + receive_auth_key)

04

Decoding rejects forward payloads that incorrectly use the auth-key AAD and receive payloads that omit it

05

Router trait and all callers updated to propagate receive auth key from NodeSigner

06

Test vectors and mock signers updated to provide deterministic receive auth keys

Risk score

Why this scored 35/100

Our methodology →
Potential impact 8/30
Exploitability 5/25
Stealth signal 6/15
Affected reach 7/15
Confidence 6/10
Evidence quality 3/5
Human-validated context

Community notes

Notes can correct, qualify, or add evidence to the AI analysis. Every note shown here has been validated by a human moderator.

No validated notes yet.

The AI analysis stands alone for now. Submit a note if you can add evidence or important context.