Repository navigation
Add HD1 v3: the same envelope over opaque bytes - #27
Merged
Merged
Conversation
…JSON HD1 v2 is JSON-only, so a PDF has to be base64'd into it at a 33% cost — the difference between a 24 MB upload cap and a 32 MB one. v3 is the same envelope over opaque bytes; isHD1 lets a store read plaintext and sealed objects side by side while it migrates between them. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
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.
Why
encryptVaultV2/decryptVaultV2are JSON-only —JSON.stringifyin,JSON.parseout. That is right for a vault blob and wrong for a payload that is already a file: base64-ing a PDF through JSON costs 33%, which is the difference between a 24 MB upload cap and a 32 MB one.HD1 v3 is the same 32-byte header (
"HD1" | version | vaultKeyId(16) | iv(12)) over an opaque byte payload. Every existing guard — the magic check, the minimum length — works unchanged, and the version byte is what says whether the plaintext is UTF-8 JSON or bytes.What changed
encryptBytes(data, dek)/decryptBytes(blob, dek)— v3 seal/open.isHD1(blob)— a cheap magic+length check, for a store that must read plaintext and sealed objects side by side while it migrates between them.sealHD1/openHD1with v3 rather than carrying its own copy of the header layout, so the format is stated once.decryptVaultnames a v3 blob instead of failing with a confusing version error.Additive: no existing signature moved.
Tests
8 new cases in
tests/crypto.test.ts— round-trip (including an empty payload), the exact header bytes and length (32 + len + 16), wrong key, tampered payload, truncated, non-HD1, and v2/v3 unconfusable in both directions. 93 tests green.Consumer
tinytars/lexi— encrypting uploaded original documents at rest under per-file content keys held in the encrypted vault, so the operator holds no standing key that opens a patient's files.🤖 Generated with Claude Code