mirror of
https://github.com/hanzoai/cek.git
synced 2026-10-09 02:37:18 +00:00
zeekayandHanzo Dev
f9255eacf9
A key derived from the master and the namespace: not generated, not wrapped, not stored, not rotated in place. That removes the unwrap step, the rewrap step, the per-file key material, and the plaintext-to-encrypted migration — every one of which existed to carry old data forward, and none of which is a property anyone wanted. A database is born encrypted or it does not exist. The same namespace and subsystem always derive the same key, so a file reopens after a restart with nothing persisted beside it, and two databases never share a key because the subsystem is part of the binding. Losing the master loses the data. That is what encryption at rest means, and why the master lives in KMS. Co-authored-by: Hanzo Dev <[email protected]>
971 B
971 B
cek
Opens a namespace's SQLite database encrypted at rest.
db, err := cek.Open(master, ns, "treasury", dataDir)
The key is derived from the master and the namespace. It is not generated, not wrapped, not stored, and not rotated in place — so there is no unwrap step, no rewrap step, no per-file key material to lose, and no migration path to maintain. A database is born encrypted or it does not exist.
Losing the master loses the data. That is the property you want from encryption at rest, and the reason the master lives in KMS.
Where it sits
hanzoai/namespace |
names the entity, and where its file lives |
hanzoai/cek |
turns the master + that name into the file's key, and opens it |
hanzoai/sqlite |
opens a file under a raw key; knows nothing about who owns it |
hanzoai/kms |
holds the master |
Nothing here knows about orgs, users, billing or plugins. It knows a namespace, a subsystem, and a master key.