# ArchiveGuard (CLI prototype) ArchiveGuard is the "Pro" tier tool in the same product line as the sibling tools VaultZip and PrivacySweep, and its job is combining both of their jobs into one safe pipeline: archive-then-verify-then-securely-shred. A `seal` run packs your source files into an AES-256-GCM encrypted vault, then decrypts and extracts that just-written vault into a temporary directory and SHA-256 byte-compares every extracted file against its original, and ONLY IF that round-trip verification fully passes does it securely overwrite-and-remove the original source files. A source file is never shredded until its archived copy has been cryptographically proven recoverable. This differs from VaultZip, which only does plain pack/unpack with no verification and never touches your originals, and from PrivacySweep, which does standalone secure deletion with no archiving or correctness guarantee at all -- ArchiveGuard's whole reason to exist is the safe "move into cold storage" workflow that chains both operations together with a hard verification gate in between, so a corrupted or truncated vault can never cost you your only copy of a file. The on-disk vault format intentionally matches VaultZip's format exactly (magic header, salt/nonce layout, AES-256-GCM, tar+gzip payload) so vaults produced by either tool are interchangeable -- ArchiveGuard implements the format fresh in its own code rather than importing VaultZip's package, but the wire format is identical by design. The WinUI 3 shell and in-app archive preview described in the full product concept are on the roadmap and not part of this CLI prototype -- see ../plan.md for the full product plan. ## Build from source Requires Go 1.24+, no external dependencies (stdlib only). go build -o archiveguard . Cross-compile for other platforms, e.g.: GOOS=windows GOARCH=amd64 go build -o archiveguard.exe . GOOS=darwin GOARCH=amd64 go build -o archiveguard . GOOS=darwin GOARCH=arm64 go build -o archiveguard . GOOS=linux GOARCH=amd64 go build -o archiveguard . ## Vault format offset size field 0 6 magic "VLTZ1\n" 6 16 salt 22 12 AES-GCM nonce 34 ... AES-256-GCM ciphertext of gzip(tar(files)) Key derivation: 200,000 rounds of iterated SHA-256 over (password + salt). This is a dependency-free stand-in for PBKDF2 so the tool builds with plain `go build` and no external modules -- it has NOT been independently audited, the same disclosure VaultZip makes about its own key stretching. For real-world secret storage, prefer an audited KDF implementation (e.g. golang.org/x/crypto/pbkdf2 or argon2). ## Usage archiveguard seal [ ...] -o --password [--apply] Packs the given file(s)/directory(ies) into an encrypted vault at the path given by -o/--output. Then, regardless of --apply, it decrypts and extracts that just-written vault into a temporary directory and SHA-256 compares every extracted file against its original source. If any file is missing or mismatched, the whole operation ABORTS loudly, the temporary directory is removed, and no source file is touched -- a failed verification must never lead to data loss. If verification passes and --apply was given, every original source file is then securely erased: multiple passes of random-data overwrite followed by fsync, then removed from disk (the same mechanism the sibling PrivacySweep tool uses standalone). If verification passes but --apply was NOT given, the vault has still been created for real and still been genuinely verified -- only the shredding step is skipped, and the tool reports how many files it would have shredded. Nothing about the vault-creation or verification steps is faked or skipped in a dry run; only the destructive shred step is gated behind --apply. archiveguard open -o --password Decrypts and extracts a vault's contents into the given output directory. A wrong password fails loudly via AES-GCM authentication (a clear error and non-zero exit), never silent garbage output. archiveguard verify --password Authenticates a vault and lists its contents (name, size, SHA-256) without extracting anything to a permanent location. Useful for confirming a vault is intact and the password is correct before committing to a full `open`. archiveguard help Prints usage. ## Safety notes - seal always writes the vault to a temp file in the destination directory and renames it into place, so a failure partway through never leaves a half-written vault at the final path. - The seal->verify->shred sequence is strict and one-directional: verification always happens before any shredding is even considered, and a failed verification always aborts before touching originals, regardless of whether --apply was passed. - The temporary directory used for round-trip verification is always removed before seal exits, on both the success and failure paths. ## Prebuilt binaries See ../downloads/ for prebuilt binaries (Windows/macOS/Linux) and CHECKSUMS.txt for their SHA-256 hashes. Unsigned indie builds -- Windows SmartScreen and macOS Gatekeeper will warn on first run, expected until a code-signing certificate is in place.