# 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.