feat: encrypt stored records with AES-256-GCM - #17
Merged
Conversation
Contributor
Author
|
@coderabbitai pause |
|
Note Reviews pausedUse the following commands to manage reviews:
Use the checkboxes below for quick actions:
Comment |
✅ Action performedReviews paused. |
DavidCozens
force-pushed
the
stage-16-mtls
branch
from
August 16, 2026 21:51
6eb1562 to
e0b507e
Compare
SolidSyslogMbedTlsAesGcmPolicy replaces the HMAC policy on the store. Records at rest gain confidentiality on top of tamper-evidence: the body is encrypted, the record header is authenticated as associated data, and nonce and tag go in the trailer. Flash +13,788 B (+164 on the previous stage) RAM +39,536 B (+12) Log stack +680 B (unchanged) Service +3,768 B (unchanged) AES-GCM is already linked: a device negotiating a GCM ciphersuite for TLS carries the same primitive the store now uses. The policy encrypts in place, into the buffer the store already owns. The store key is unchanged. Its name states what it protects rather than which algorithm protects it, so escalating the policy needs no new key provisioned. GCM needs a fresh nonce per record and mbedTLS has no context-free RNG, so the policy takes the device's DRBG as well as the key. That is the only wiring difference from the HMAC policy. The pipeline element now derives both values from what the device holds, and each falls back to the weakest honest answer when the credential behind it is missing. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
DavidCozens
force-pushed
the
stage-17-aes-gcm
branch
from
August 16, 2026 21:52
bf9eb36 to
695d00e
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Replace the HMAC policy with authenticated encryption. Tamper-evidence establishes that a stored
record was not altered; it does nothing to stop anyone reading it. AES-256-GCM encrypts the body,
authenticates the record header as associated data, and puts the nonce and tag in the trailer.
GCM needs a fresh nonce per record and mbedTLS has no context-free RNG, so the policy takes the
device's DRBG as well as the key. That is the only wiring difference from the HMAC policy.
The store key does not change. Its name states what it protects rather than which algorithm protects
it, so escalating the policy needs no new key provisioned.
These are separate decisions and the second does not follow from the first. A device that only needs
to prove records were not altered can stop at the HMAC.
The pipeline element now derives both of its values from what the device holds, and each falls back
to the weakest honest answer when the credential behind it is missing:
When you need it. If a disk that leaves the device would give something away — records naming
users, addresses, process values, or anything else you would not publish.