cristiancmoises/zupt
Watch
1
0
Fork
You've already forked zupt
 0
Code Issues Pull requests Projects Releases 1 Packages Wiki Activity Actions 3

docs: complete zupt → vaptvupt rename; README v4.0.0 refresh

Browse source 
- README: add 'What's new in 4.0.0' section, extend release history
  v2.2.4 → v4.0.0, fix stale section titles (benchmark/security/feature
  tables), point fast-install at short.securityops.co/vaptvupt, fix
  related-project links (vaptvupt-codec, libvuptsdk, real repo names)
- install.sh: clone the renamed repo, vaptvupt success message
- Rename remaining zupt → vaptvupt across INSTALL.md, DISTRIBUTION.md,
  SECURITY.md, THREAT_MODEL.md, ROADMAP.md, THIRD-PARTY-NOTICES.md,
  gui/ + sdk/ + packaging READMEs, doc/vaptvupt.1, spec comments/URLs
- New doc/vaptvupt-gui.1 (GUI 1.3.0, VAPTVUPT_BIN/ZUPT_BIN env vars);
  doc/zupt-gui.1 kept as hardlinked compat copy
- Deliberately unchanged: .zupt extension, ZUPT header magic,
  ZUPT-* crypto domain-separation constants, zupt_*/ZUPT_* code
  identifiers, libzuptsdk artifact names, legacy symlink notes,
  CHANGELOG/AUDIT historical entries, Provides/Obsoletes upgrade path
- tests/test_packaging_syntax.sh: THREAT_MODEL section titles updated
This commit is contained in:
Cristian Cezar Moisés 2026-06-11 21:46:20 -03:00
commit 136a96ed20
18 changed files with 471 additions and 306 deletions
Download patch file Download diff file Expand all files Collapse all files

42
THREAT_MODEL.md
View file

@ -1,21 +1,21 @@
# Zupt threat model
# VaptVupt threat model
Plain-English description of what Zupt protects against, what it
Plain-English description of what VaptVupt protects against, what it
doesn't, and what assumptions you're making when you use it.
This document is for users and downstream packagers. Read it before
trusting Zupt with anything you can't afford to lose.
trusting VaptVupt with anything you can't afford to lose.
---
## TL;DR
Zupt is designed for **at-rest backup encryption** by someone who
VaptVupt is designed for **at-rest backup encryption** by someone who
controls the machine doing the encryption and the machine doing the
extraction. It is **not** a network protocol, a multi-party scheme, or
a substitute for full-disk encryption.
| Use case | Zupt is appropriate? |
| Use case | VaptVupt is appropriate? |
|---|---|
| Backing up files to an untrusted cloud (S3, Backblaze, Google Drive) | **Yes** |
| Backing up a disk image to external media you might lose | **Yes** |
@ -28,7 +28,7 @@ a substitute for full-disk encryption.
---
## What Zupt protects against
## What VaptVupt protects against
### 1. Confidentiality of archive contents (encrypted mode)
@ -109,14 +109,14 @@ accesses where feasible — but **without formal proof**.
---
## What Zupt does NOT protect against
## What VaptVupt does NOT protect against
This list is **exhaustive of the major omissions** — if you have a
concern that doesn't appear here, please file an issue.
### 1. Compromised endpoints
Zupt cannot protect against:
VaptVupt cannot protect against:
- Malware on the machine doing the encryption (it sees plaintext
before any crypto is applied)
@ -127,14 +127,14 @@ Zupt cannot protect against:
`~/.zupt-key` directly
- Cold-boot attacks on running machines
If you don't trust the machine, Zupt cannot help.
If you don't trust the machine, VaptVupt cannot help.
### 2. Key compromise
If the password or `~/.zupt-key` is leaked:
- All archives encrypted with that key are decryptable
- Zupt has **no forward secrecy across archives** — each archive
- VaptVupt has **no forward secrecy across archives** — each archive
is encrypted under a single static key derived from the password
or stored in the key file
- There is no key-rotation feature; rotate by re-encrypting
@ -160,7 +160,7 @@ clusters or cloud compute.
| Random 16-char with full alphabet | Infeasible without quantum breakthrough |
For critical data, use `--pq-sdk` mode with a random key file
generated by `zupt keygen --sdk` — the key is 64 bytes of CSPRNG
generated by `vaptvupt keygen --sdk` — the key is 64 bytes of CSPRNG
output, not derived from human-typed text.
### 4. Metadata leakage from archive structure
@ -180,13 +180,13 @@ can infer:
- **A random 16-byte UUID per archive** (no information leak, but
globally identifies the archive across copies)
If metadata privacy matters, layer Zupt under another tool that
If metadata privacy matters, layer VaptVupt under another tool that
hides bulk metadata (e.g., put the `.zupt` file inside a fixed-size
encrypted container).
### 5. Network attacks
Zupt is not a network protocol. There is no:
VaptVupt is not a network protocol. There is no:
- Forward-secure session establishment (use TLS or Noise)
- Mutual authentication of remote parties (use signed messages or
@ -205,9 +205,9 @@ they must share the password or the key file.
### 7. Plausible deniability / hidden volumes
Zupt archives have a fixed 6-byte magic `\x90\x5a\x55\x50\x54\x01`
at offset 0. Anyone scanning the bytes can see it's a Zupt
archive. Zupt has **no hidden-volume or duress-password feature**.
VaptVupt archives have a fixed 6-byte magic `\x90\x5a\x55\x50\x54\x01`
at offset 0. Anyone scanning the bytes can see it's a VaptVupt
archive. VaptVupt has **no hidden-volume or duress-password feature**.
### 8. Side channels we don't claim to address
@ -241,7 +241,7 @@ primary mitigation; report bugs.
### 11. Compression-side-channel attacks (CRIME / BREACH style)
Zupt compresses **before** encryption. If an attacker can:
VaptVupt compresses **before** encryption. If an attacker can:
- Influence part of the plaintext (e.g. inject a known prefix)
- Observe the resulting archive size precisely
@ -250,7 +250,7 @@ then they can use the compression ratio to learn information about
the rest of the plaintext — this is the classic CRIME/BREACH attack
against TLS compression.
Zupt is designed for offline backup, where attacker-controlled
VaptVupt is designed for offline backup, where attacker-controlled
plaintext injection is rare. **If your threat model includes
attacker-chosen plaintext mixed with secret plaintext in the same
archive**, use `--no-compress` (codec 0 = STORE) to disable the
@ -260,7 +260,7 @@ LZ codec and eliminate this side channel.
## Cryptographic assumptions
Zupt's security rests on the following standard assumptions:
VaptVupt's security rests on the following standard assumptions:
| Assumption | What breaks if it fails |
|---|---|
@ -272,7 +272,7 @@ Zupt's security rests on the following standard assumptions:
| HKDF-SHA256 is a secure key-derivation construction | Combined PQ + classical keys may be predictable |
| SHA3 / SHAKE retain pre-image and collision resistance | Auxiliary protocol bindings may be forged |
If you don't trust one of these primitives, Zupt cannot protect
If you don't trust one of these primitives, VaptVupt cannot protect
you. We rely on the same primitives the broader cryptographic
community has standardized.
@ -280,7 +280,7 @@ community has standardized.
## Reporting security issues
Email `sac@securityops.co` with the subject `Zupt security report`.
Email `sac@securityops.co` with the subject `VaptVupt security report`.
PGP key available on request.
We will: