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

Encrypt `payment_metadata` when we build the payment secret

Public commit record

What the developer wrote

Authored by Matt Corallo

85/100 · Strong
Encrypt `payment_metadata` when we build the payment secret

In 657ac8f58e51af74c610375cb65cdad6f7a18c6b we started committing
to the `payment_metadata` in the `payment_secret`. We'd largely
assumed that downstream code could simply encrypt the
`payment_metadata` itself before passing it to `lightning` and
decrypt before reading it from `lightning`. However, this presents
a challenge - we'd very much love for that downstream code to avoid
adding any extra bytes to its `payment_metadata` if at all
possible, but it doesn't have a great way to get a decent IV
without simply shoving it in the encrypted `payment_metadata`.

Instead, here, we encrypt and decrypt the `payment_metadata`
internally in `lightning`. This allows us to reuse the IV that is
used for `lightning`-generated `payment_hash`es as the IV for the
encrypted `payment_metadata` as well. Sadly, we don't have any
similar IV for user-provided `payment_hash`es. In that case, we
simply accept the limitations and document that users must avoid
encrypting multiple `payment_metadata`s for payments with the same
`payment_hash`. This avoids padding the size of the
`payment_metadata` and should generally not be a material concern -
`payment_hash` reuse should generally not exist anyway, and if it
does it should only be in cases where its "the same payment" being
retried after failure, at which point `payment_metadata` should
hopefully be the same.
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Explains rationale or failure mode
The short version

What changed, and why it matters

This commit changes how Lightning Dev Kit handles optional extra data attached to incoming payments (called payment_metadata). Previously, LDK expected downstream applications to encrypt that data themselves before handing it to LDK. Now LDK encrypts and decrypts it internally, reusing random values already generated for payment secrets. The goal is to avoid making invoices larger by adding separate encryption overhead. For payments where the user supplies their own payment hash, a fresh random value is appended to the encrypted metadata, with a documented warning that reusing the same payment hash with different metadata is unsafe. The change is a privacy/usability improvement, not a fix for an active vulnerability, and it includes new tests covering the three ways metadata can be created.

Recommended action

Reviewers should confirm that the ChaCha20 nonce/IV construction is never reused for the same key under realistic usage, especially for the LDK-generated payment_hash path where the IV is deterministic from the payment_secret. Verify that the HMAC over encrypted metadata is computed before encryption and after decryption consistently, and that callers cannot accidentally pass plaintext metadata into the new API. Consider whether the user-hash IV-appended format needs a version or length prefix for future compatibility. No urgent security patch is indicated, but downstream users should update to the new API and stop pre-encrypting metadata.

Security signals we found

01

New symmetric encryption key derived via HKDF-SHA256

02

ChaCha20 used as a stream cipher for metadata confidentiality

03

Metadata is included in the existing payment_secret HMAC, providing integrity

04

User-supplied payment_hash path appends a random IV, with documented reuse limitation

05

Spontaneous payments now explicitly reject payment_metadata

06

API rename get_payment_preimage -> get_payment_preimage_decrypt_metadata

Risk score

Why this scored 34/100

Our methodology →
Potential impact 8/30
Exploitability 5/25
Stealth signal 4/15
Affected reach 6/15
Confidence 7/10
Evidence quality 4/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.