Panic mode

Emergency vault destruction from the GUI.

Panic mode overwrites a vault's header with random bytes so the encrypted content becomes mathematically unrecoverable. Use this when you need to destroy a vault quickly. Open it from the sidebar with PANIC: destroy a vault.... There is no undo.

Panic view: red title 'PANIC: irreversibly destroy a vault', a Target section with the vault path field, Browse..., the checkbox 'This vault uses a detached header sidecar' and the checkbox 'ALSO overwrite the entire vault data area with random (slow on large vaults)', and a Confirm section asking to type DESTROY followed by the path — Panic mode. Designed to be hard to trigger by accident: the Destroy button stays disabled until you type DESTROY followed by the exact vault path.

What panic mode does

Fill in the Target section: the vault path (or Browse...), and, if the vault uses a detached header, tick This vault uses a detached header sidecar and give the header's path.

Choice	What it does	When to pick
Default	Overwrites the 8 KiB header (or the detached `.hdr` file) with random bytes, and overwrites the header's crash-recovery copy (`.header-bak` next to it) completely, so the header cannot be rebuilt from it. The encrypted data stays on disk but is unreadable.	Fast destruction; takes the same time whatever the vault size
ALSO overwrite the entire vault data area with random (slow on large vaults)	The above, plus overwrites the whole vault file and its metadata copy (`.meta-bak`) with random bytes. The file keeps its size.	Full destruction; takes time proportional to vault size

On success the GUI says "vault destroyed", returns to the Welcome view and removes the vault from the recent-vaults list.

Why this is mathematically unrecoverable

Without the 8 KiB header you have:

No magic bytes (LUKSBOX2 / LUKSBOX3) to confirm the file is a vault
No salt
No keyslot table (no wrapped MVK ciphertexts to brute-force)
No KDF parameters
No header HMAC (so even if you guessed the MVK, no way to verify)
No cipher_suite / kdf_id fields

Even an attacker with infinite compute can't unlock a header-less vault because there's nothing to attack - the wrapped MVK ciphertexts that would normally take Argon2id-bounded time to brute-force are GONE.

The confirmation gate

The Destroy button stays disabled until you:

Enter the vault path
Type DESTROY, a space and the exact vault path in the Confirm field, as the form shows it (for example DESTROY /home/you/vault.lbx)

This isn't there to make you feel safer; it's there because panic mode has no undo. If you accidentally panic the wrong vault, your only recovery is a header backup made beforehand with luksbox header-backup (which we strongly recommend keeping on separate trusted storage), and only if you did not overwrite the data area too.

Use cases

Situation	Recommended panic mode
Selling / scrapping a hard drive	Tick ALSO overwrite the entire vault data area
Border crossing with sensitive data	Header only (fast); restore from a header backup later
Compromised device + you have time	Tick ALSO overwrite the entire vault data area
Compromised device + URGENT (panic-button scenario)	Header only - fastest path to "unrecoverable"
Suspected insider threat	Header only, with a header backup kept elsewhere; investigate then restore

What survives panic

Panic does NOT touch:

Other files next to the vault: the .anchor sidecar, the .hybrid sidecar, the .kyber seed file. Delete them yourself if they must not show that a vault existed.
Header backups you made with luksbox header-backup.
OS-level file metadata (creation time, last-access time)
Forensic recovery of the original header bytes from disk slack or filesystem journal if you only overwrite the header and the filesystem journals deletions (tick ALSO overwrite the entire vault data area on journaled FSes for stronger destruction). SSDs and copy-on-write filesystems may also keep old copies of overwritten blocks.

Back to GUI overview ->
CLI equivalent: luksbox panic -> (--header, --wipe-data; no GUI confirmations, -y skips the prompt)