Security model Preview
What SQZ Backup's encryption protects, what it deliberately does not, and how the keys work. Plain .sqz archives are not encrypted; everything here is about sqz backup.
What is protected#
- Confidentiality. File contents, names, sizes and metadata are encrypted. Someone who holds the repository but no key sees only encrypted objects.
- Integrity. Any change to stored data or metadata by someone without the key is detected on read and by
check. A restore never silently returns different bytes. - Crash safety. An interrupted backup never exposes a snapshot with missing data and never damages an older one.
- Clear failures. A wrong password, a missing object and a tampered object each give a specific error, named per object.
Who it defends against#
| Who | What they can do | What stops them |
|---|---|---|
| Whoever holds the storage: a cloud provider, a NAS admin, anyone who copies the folder | Read every object and see sizes and write times; delete, change, reorder, replace or replay objects | Everything is encrypted and authenticated; object IDs are keyed, so known files cannot be looked up by hash; tampering is detected |
| A thief of the backup disk | The same, offline, with time to guess passwords | The same, and the password is stretched with Argon2id (64 MiB of memory per guess) |
| Accidents: crashes, power loss, full disks, bit rot | Leave partial or damaged files | Write-then-publish order; every object is checked by hash and authentication tag |
What it does not protect against#
- A compromised computer while the repository is unlocked. Malware on the machine running the backup can read what it reads.
- Deletion. Someone who holds the storage can delete it. The answer is a second copy (
copy), not cryptography. - Rolling back the whole repository. Someone can put back an older complete copy of the folder. Each computer remembers the newest snapshot it has seen and notices this, but a fresh computer cannot.
- Size and timing. The holder sees how many packs exist, their sizes and when they were written, so roughly how much changed and when. Individual file sizes are not directly visible, but published research on content-defined chunking shows that chunk-size patterns can still help confirm whether a known file is present. SQZ keys its chunker per repository, which makes this harder but does not remove it.
Cryptography#
No custom ciphers or constructions; only well-reviewed libraries, used as documented.
| Purpose | Choice |
|---|---|
| Encryption of every object | XChaCha20-Poly1305 (RustCrypto chacha20poly1305, reviewed by NCC Group in 2020), random 192-bit nonces |
| Password stretching | Argon2id, 64 MiB, 3 passes (RFC 9106) |
| Subkeys from the master key | BLAKE3 key derivation, one subkey per purpose |
| Object IDs | Keyed BLAKE3, so IDs of known content cannot be computed |
| Randomness | The operating system's generator |
| Keys in memory | Wiped when no longer needed |
Keys, passwords and the recovery key#
At init, SQZ makes a random 256-bit master key. It is never stored in the clear, only wrapped in key slots:
- a password slot for each password (Argon2id with a random salt);
- a recovery slot for the recovery key, shown once at
initas 56 characters in groups of four, including a checksum that catches typos.
A wrong password or recovery key fails cleanly with "wrong password (or this is not the key for this repository)". Adding a password (add-password) wraps the same master key in a new slot; nothing else is rewritten.
There is no back door. Keep the recovery key written down somewhere safe and separate from the computer you back up.
A swapped config#
Someone with write access could replace the repository's config with one that wraps a key they know, hoping your next backup is written under it. The config is authenticated with a subkey of the master key, and each computer remembers a check value for every repository it has used. A config under another key is refused on those computers.
Not built yet#
- Removing a password or exporting a key file.
- Rotating the master key. After a suspected compromise, copy the data into a new repository instead.