Skip to content

Conversation

@tnull
Copy link
Contributor

@tnull tnull commented Nov 28, 2025

We add support for option_message_padding (feature ??) as proposed in lightning/bolts#1304.

When both parties signal support for `option_message_padding`, we pad
any sent messages to a fixed size to improve privacy in the face of
an adversary monitoring network traffic.

To this end we utilize an optional TLV-stream extension with an odd
field number of `u64::max_value()` that simply will be discarded by the
counterparty. The padding threshold is chosen to fit even the largest
standard Lightning messages (UpdateAddHtlc) whith some leeway to
guarantee package size uniformity even when some of the optional fields
are set.

@ldk-reviews-bot
Copy link

ldk-reviews-bot commented Nov 28, 2025

👋 Hi! This PR is now in draft status.
I'll wait to assign reviewers until you mark it as ready for review.
Just convert it out of draft status when you're ready for review!

@tnull tnull marked this pull request as draft November 28, 2025 14:16
@tnull tnull force-pushed the 2025-11-option-message-padding branch 3 times, most recently from d618e6a to a8e3199 Compare November 28, 2025 14:42
We add prototypical support for the `option_message_padding` feature
while the BOLTs PR is still underway.
When both parties signal support for `option_message_padding`, we pad
any sent messages to a fixed size to improve privacy in the face of
an adversary monitoring network traffic.

To this end we utilize an optional TLV-stream extension with an odd
field number of `u64::max_value()` that simply will be discarded by the
counterparty. The padding threshold is chosen to fit even the largest
standard Lightning messages (UpdateAddHtlc) whith some leeway to
guarantee package size uniformity even when some of the optional fields
are set.

Note that even without padding we surpassed the standard Ethernet MTU of
1500 bytes for `UpdateAddHtlc` messages, so fitting the packets into
exactly 1500 bytes is a futile endeavor. Furthermore note that any
messages above that threshold size will still stand out in monitored
network traffic. Lastly, we opt to *not* apply padding for any
custom messages, as they might not be set up to handle the optional TLV
extension.
While it shouldn't really make any difference for the Noise protocol, we
here avoid taking any chances w.r.t. known plaintext attacks and opt to
randomize the padding data.
@tnull tnull force-pushed the 2025-11-option-message-padding branch from a8e3199 to 5052f4d Compare November 28, 2025 15:13
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants