1.5 KiB
Repository encryption threat model
Status
This document defines the M11 repository-encryption boundary. Encrypted repository creation remains disabled until the recovery host-loss acceptance test passes.
Confidential data
For an aes-256-gcm repository, blob contents and signed manifest contents are
AEAD-encrypted. Data keys and signing private keys are never stored in repository
metadata, SQLite, logs, command arguments, environment output, or API responses.
Recovery bundles are separately passphrase-encrypted.
Intentional leakage
The v1 content-addressed layout retains plaintext SHA-256 blob names. Encryption therefore leaks blob equality, object count, repository layout, manifest/backup identifiers, and ciphertext sizes derived from plaintext sizes. It does not claim to hide those values, a compromised running host with unlocked keys, source data while it is read, or a recovery-bundle passphrase.
Key lifecycle
Encryption uses distinct data and signing keys. Rotation creates a new data-key epoch for subsequent objects and retains historical epochs so existing backups remain verifiable and restorable. It neither changes immutable repository policy nor rewrites existing objects.
Recovery boundary
Recovery export, validation, and import are local CLI operations only. A bundle contains the required key material and an authenticated catalog; passphrases are not accepted on command lines. Bundle parsing must reject malformed or unsupported parameters without revealing whether a passphrase, key, or ciphertext was wrong.