brontide: use a static buffer for the packet length
What the developer wrote
Authored by Olaoluwa Osuntokun
brontide: use a static buffer for the packet length
In this commit, we eliminate the final allocation that takes place when
we write out messages. Once again this was escaping to the heap, so we
make it an attribute on the Machine struct, which allows pure static
allocation.
```
goos: darwin
goarch: arm64
pkg: github.com/lightningnetwork/lnd/brontide
cpu: Apple M4 Max
BenchmarkWriteMessage-16 25840 46376 ns/op 2 B/op 0 allocs/op
BenchmarkWriteMessage-16 25646 46672 ns/op 2 B/op 0 allocs/op
BenchmarkWriteMessage-16 25874 46391 ns/op 2 B/op 0 allocs/op
BenchmarkWriteMessage-16 25512 46427 ns/op 2 B/op 0 allocs/op
BenchmarkWriteMessage-16 25760 46309 ns/op 2 B/op 0 allocs/op
BenchmarkWriteMessage-16 25789 46520 ns/op 2 B/op 0 allocs/op
BenchmarkWriteMessage-16 25602 46619 ns/op 2 B/op 0 allocs/op
BenchmarkWriteMessage-16 25766 46464 ns/op 2 B/op 0 allocs/op
BenchmarkWriteMessage-16 25820 46487 ns/op 2 B/op 0 allocs/op
BenchmarkWriteMessage-16 25634 46553 ns/op 2 B/op 0 allocs/op
PASS
ok github.com/lightningnetwork/lnd/brontide 16.907s
```
What changed, and why it matters
This is a routine performance optimization, not a security fix. The developer replaced a small temporary memory allocation with a reusable buffer inside a connection object to reduce memory allocations when sending encrypted messages. There is no security-relevant change here.
No security action needed. Treat as a normal performance/refactoring commit.
Security signals we found
No strong security signals were identified.
Evidence from the diff
The commit modifies brontide/noise.go to add a fixed-size [lengthHeaderSize]byte field (pktLenBuffer) to the Machine struct and uses it instead of a local var pktLen [2]byte when encoding the 2-byte packet length before encryption. This eliminates a heap escape/allocation in WriteMessage. The functional behavior is identical: the same 2-byte big-endian length is produced and passed to the same Encrypt call. No input validation, cryptographic operations, state machine, or protocol logic is changed.
Changed components
brontide/noise.goMachine.WriteMessageInspect captured patch +5 / −3
diff --git a/brontide/noise.go b/brontide/noise.go
index 56c4c34..bdd9228 100644
--- a/brontide/noise.go
+++ b/brontide/noise.go
@@ -385,6 +385,9 @@ type Machine struct {
// (of the next ciphertext), followed by a 16 byte MAC.
nextCipherHeader [encHeaderSize]byte
+ // pktLenBuffer is a reusable buffer for encoding the packet length.
+ pktLenBuffer [lengthHeaderSize]byte
+
// nextHeaderSend holds a reference to the remaining header bytes to
// write out for a pending message. This allows us to tolerate timeout
// errors that cause partial writes.
@@ -751,11 +754,10 @@ func (b *Machine) WriteMessage(p []byte) error {
// NOT include the MAC.
fullLength := uint16(len(p))
- var pktLen [2]byte
- binary.BigEndian.PutUint16(pktLen[:], fullLength)
+ binary.BigEndian.PutUint16(b.pktLenBuffer[:], fullLength)
// First, generate the encrypted+MAC'd length prefix for the packet.
- b.nextHeaderSend = b.sendCipher.Encrypt(nil, nil, pktLen[:])
+ b.nextHeaderSend = b.sendCipher.Encrypt(nil, nil, b.pktLenBuffer[:])
// Finally, generate the encrypted packet itself.
b.nextBodySend = b.sendCipher.Encrypt(nil, nil, p)
Why this scored 15/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.