36 lines
1.5 KiB
Markdown
36 lines
1.5 KiB
Markdown
# 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.
|