Your Data. Your Rules.

It is a pre-v1, and we are upfront about that. The on-disk format is locked, the cryptographic primitives are NIST/RFC standards built on RustCrypto, thirteen rounds of internal audit have shipped (every CRITICAL + HIGH + MEDIUM finding fixed in the same revision that surfaced it; 30M+ fuzz iterations across 15+ harnesses), and a workspace-wide audit of secret-memory handling + filesystem TOCTOU + sidecar DoS landed in 2026-05. External paid audit and broader real-world deployment are the next milestones. The cloud-storage threat model, provider can't read your data even under subpoena, is what it is built for and what it does today. The 'compromised-host-after-unlock' threat model is, and will remain, out of scope for any user-space tool. See the security architecture and the threat model.

Storing sensitive files on places you do not fully trust: cloud storage (iCloud, Google Drive, Dropbox, OneDrive, S3, Backblaze), network shares and NAS units managed by someone else, USB sticks that travel, backup media that lives outside your physical reach. You encrypt locally with your keys, drop the resulting .lbx wherever, and mount it back as a real drive when you need it. The provider sees one opaque blob and cannot decrypt it even under legal compulsion. Read the comparison page for the head-to-head against provider encryption, LUKS2, VeraCrypt, age, gocryptfs, and BitLocker / FileVault.

No. Use LUKSbox to make a secondary copy that is safe to share or store in places you don't control (cloud sync, USB drive, vault sent to a colleague or client). Like any encrypted container, a .lbx is a single point of failure: if the file is corrupted, lost, or every keyslot becomes inaccessible, the data is gone. The forensic toolkit (header-backup, check, extract --tolerate-errors) helps in many damage scenarios but cannot recover bytes that are no longer on disk or no longer AEAD-tagged. Always keep an unencrypted copy somewhere you trust for any file you cannot afford to lose. See the Disclaimer for the no-warranty / no-liability details.

LUKSbox ships a forensic toolkit on par with cryptsetup's luksHeaderBackup plus chunk-level inspection on top. luksbox check walks every chunk and pinpoints which one fails AEAD with file path + on-disk offset. luksbox extract --tolerate-errors salvages a file by zero-filling the bad chunks. luksbox header-backup saves the 8 KiB header before changes; luksbox header-restore reinstates a saved header (HMAC-verified by default to prevent attacker-substituted backups). luksbox header-dump emits the decrypted file tree as JSON for forensics. Full walkthrough on the Forensics page.

No. LUKSbox uses its own on-disk format (LBXVAULT magic, custom 8 KiB header) optimised for FIDO2 + TPM 2.0 + post-quantum keyslots and detached-header mode. The name borrows the LUKS spirit; the bytes are different. cryptsetup won't read a LUKSbox vault, and LUKSbox won't open a LUKS2 vault.

Hybrid keyslots derive the wrap-KEK via HKDF-SHA256 over both an Argon2id-stretched passphrase (or FIDO2 hmac-secret) AND an ML-KEM shared secret. If either primitive breaks - classical or PQ - the other still protects the vault. The Kyber seed file lives on separate trusted storage so even disk + passphrase doesn't unlock without the seed.

Yes - every vault can have a passphrase keyslot. FIDO2, Windows Hello, TPM 2.0, and hybrid-PQ are optional additional keyslots. You can mix any combination in the same vault.

VeraCrypt has no hardware-key or post-quantum support. LUKS2 added FIDO2 via systemd-cryptenroll but no PQ and no TPM-as-a-keyslot. LUKSbox is built around all of those as first-class slot kinds, in memory-safe Rust, fully open source under Apache 2.0. See the comparison page and docs/PROJECT_OVERVIEW.md Sec.4 for the head-to-head.

We explicitly want external eyes on the fuzzing corpus and on the integration layer. The security tests page lists each fuzz target's status, the regression suite, and four concrete contribution paths (corpus seeds, new fuzz harnesses, regression-test suggestions, AFL++ campaigns). Suspected vulnerabilities go to GitHub issues.

Open source under the Apache License 2.0. You can read, audit, build, modify, redistribute, and use the source in any product including commercial ones that compete with LUKSbox. Apache 2.0 includes an explicit patent grant from every contributor, which matters for cryptography work. The Penthertz brand (the LUKSbox name and logo) is reserved via the trademark policy; see TRADEMARK.md - you can fork the code freely, you just can't call your fork "LUKSbox".