brontide: use a fixed size buffer for the nonce within the brontide machine
What the developer wrote
Authored by Olaoluwa Osuntokun
brontide: use a fixed size buffer for the nonce within the brontide machine
In this commit, we use a fixed sized buffer for the nonce when we
read/write messages. This was actually escaping to the heap. We can
avoid this by statically allocating it alongside the struct itself.
The benchmark state at this point:
```
goos: darwin
goarch: arm64
pkg: github.com/lightningnetwork/lnd/brontide
cpu: Apple M4 Max
BenchmarkWriteMessage-16 25264 47012 ns/op 4 B/op 1 allocs/op
BenchmarkWriteMessage-16 23542 46809 ns/op 4 B/op 1 allocs/op
BenchmarkWriteMessage-16 25989 47256 ns/op 4 B/op 1 allocs/op
BenchmarkWriteMessage-16 25542 46388 ns/op 4 B/op 1 allocs/op
BenchmarkWriteMessage-16 26083 46612 ns/op 4 B/op 1 allocs/op
BenchmarkWriteMessage-16 25860 46367 ns/op 4 B/op 1 allocs/op
BenchmarkWriteMessage-16 24967 46748 ns/op 4 B/op 1 allocs/op
BenchmarkWriteMessage-16 26088 46485 ns/op 4 B/op 1 allocs/op
BenchmarkWriteMessage-16 25561 46425 ns/op 4 B/op 1 allocs/op
BenchmarkWriteMessage-16 25474 47249 ns/op 4 B/op 1 allocs/op
PASS
ok github.com/lightningnetwork/lnd/brontide 16.911s
```
```
goos: darwin
goarch: arm64
pkg: github.com/lightningnetwork/lnd/brontide
cpu: Apple M4 Max
│ old.txt │ new2.txt │
│ sec/op │ sec/op vs base │
WriteMessage-16 50.34µ ± 1% 46.68µ ± 1% -7.28% (p=0.000 n=10)
│ old.txt │ new2.txt │
│ B/op │ B/op vs base │
WriteMessage-16 73788.000 ± 0% 4.000 ± 0% -99.99% (p=0.000 n=10)
│ old.txt │ new2.txt │
│ allocs/op │ allocs/op vs base │
WriteMessage-16 5.000 ± 0% 1.000 ± 0% -80.00% (p=0.000 n=10)
```
What changed, and why it matters
This change is a routine performance optimization, not a security fix. The developer replaced a temporary 12-byte nonce buffer that was repeatedly created on the fly with a fixed buffer stored inside the encryption state struct. This removes almost all memory allocations during message encryption/decryption and makes the code faster, but it does not change what data is encrypted or how keys are managed.
No security action needed. Treat as a normal performance refactor. Standard code review is sufficient.
Security signals we found
No strong security signals were identified.
Evidence from the diff
In brontide/noise.go, cipherState now carries a fixed [12]byte nonceBuffer field. Encrypt() and Decrypt() write the 64-bit little-endian nonce counter into nonceBuffer[4:] and pass nonceBuffer[:] to the AEAD Seal/Open calls, instead of allocating a fresh var nonce [12]byte on each call. The cryptographic behavior is identical: same key, same 96-bit nonce construction, same AEAD interface. The only effect is elimination of per-message heap allocations (benchmarks show B/op dropping from ~73 KB to 4 B and allocations from 5 to 1).
Changed components
brontide/noise.gocipherState.EncryptcipherState.DecryptInspect captured patch +13 / −6
diff --git a/brontide/noise.go b/brontide/noise.go
index 53f951a..56c4c34 100644
--- a/brontide/noise.go
+++ b/brontide/noise.go
@@ -91,6 +91,9 @@ type cipherState struct {
// TODO(roasbeef): this should actually be 96 bit
nonce uint64
+ // nonceBuffer is a reusable buffer for the nonce to avoid allocations.
+ nonceBuffer [12]byte
+
// secretKey is the shared symmetric key which will be used to
// instantiate the cipher.
//
@@ -117,10 +120,12 @@ func (c *cipherState) Encrypt(associatedData, cipherText, plainText []byte) []by
}
}()
- var nonce [12]byte
- binary.LittleEndian.PutUint64(nonce[4:], c.nonce)
+ // Write the nonce counter to the buffer (bytes 4-11).
+ binary.LittleEndian.PutUint64(c.nonceBuffer[4:], c.nonce)
- return c.cipher.Seal(cipherText, nonce[:], plainText, associatedData)
+ return c.cipher.Seal(
+ cipherText, c.nonceBuffer[:], plainText, associatedData,
+ )
}
// Decrypt attempts to decrypt the passed ciphertext observing the specified
@@ -135,10 +140,12 @@ func (c *cipherState) Decrypt(associatedData, plainText, cipherText []byte) ([]b
}
}()
- var nonce [12]byte
- binary.LittleEndian.PutUint64(nonce[4:], c.nonce)
+ // Write the nonce counter to the buffer (bytes 4-11).
+ binary.LittleEndian.PutUint64(c.nonceBuffer[4:], c.nonce)
- return c.cipher.Open(plainText, nonce[:], cipherText, associatedData)
+ return c.cipher.Open(
+ plainText, c.nonceBuffer[:], cipherText, associatedData,
+ )
}
// InitializeKey initializes the secret key and AEAD cipher scheme based off of
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.