Skip to content

feat: seal stored records with HMAC-SHA256 instead of CRC-16 - #62

Merged
DavidCozens merged 1 commit into
mainfrom
stage-14-hmac
Aug 16, 2026
Merged

feat: seal stored records with HMAC-SHA256 instead of CRC-16#62
DavidCozens merged 1 commit into
mainfrom
stage-14-hmac

Conversation

@DavidCozens

Copy link
Copy Markdown
Contributor

Replace the CRC-16 with a keyed HMAC. The checksum established that a record came back the way it
went in; the HMAC establishes that nobody has changed it since. An edit made without the key fails
verification, so stored records become tamper-evident rather than merely intact.

struct SolidSyslogMbedTlsHmacSha256PolicyConfig hmacConfig = {.GetKey = SyslogStoreKey};

.SecurityPolicy = SolidSyslogMbedTlsHmacSha256Policy_Create(&hmacConfig),

The key is fetched per seal and per verify rather than held, so it never sits on the policy instance.
Key custody, rotation and provisioning are yours; the library consumes a key you supply and never
stores one.

Holding a named symmetric key and handing it out is the device's own mechanism — a device already
doing mTLS has provisioned secrets and somewhere to keep them, so the key slot, the loader and the
accessor all sit below the line. What SolidSyslog is charged for is the policy and the callback that
reaches for the key.

@coderabbitai

coderabbitai Bot commented Aug 16, 2026

Copy link
Copy Markdown

Note

Reviews paused

Use the following commands to manage reviews:

  • @coderabbitai resume to resume automatic reviews.
  • @coderabbitai review to trigger a single review.

Use the checkboxes below for quick actions:

  • ▶️ Resume reviews
  • 🔍 Trigger review

Comment @coderabbitai help to get the list of available commands.

@DavidCozens

Copy link
Copy Markdown
Contributor Author

@coderabbitai pause

Base automatically changed from stage-13-tls to main August 16, 2026 17:57
SolidSyslogMbedTlsHmacSha256Policy replaces SolidSyslogCrc16Policy on the store.
Records at rest are tamper-evident rather than checksummed: an edit without the
key fails verification.

  Flash      +13,416 B  (+332 on the previous stage)
  RAM        +37,472 B     (+20)
  Log stack     +680 B  (unchanged)
  Service     +3,768 B  (unchanged)

Twenty bytes, and it is the policy's pool entry. The mechanism for holding a
named symmetric key and handing it out is the device's own, so the key slot, the
loader and the accessor all sit below the line. SHA-256 was already linked, and
the policy hashes into a caller-owned buffer, so there is no stack movement and
no heap.

The key is fetched per seal and per verify rather than held, so it never sits on
the policy instance.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
@DavidCozens
DavidCozens merged commit d524d64 into main Aug 16, 2026
@coderabbitai

coderabbitai Bot commented Aug 16, 2026

Copy link
Copy Markdown
✅ Action performed

Reviews paused.

@DavidCozens
DavidCozens deleted the stage-14-hmac branch August 16, 2026 17:58
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.

1 participant