How LUKSbox compares

Why LUKSbox: simplicity + FIDO2 + post-quantum control over your data when you don't fully trust the cloud.

Why LUKSbox exists

Most encryption tools force a trade-off: easy + weak (cloud providers' built-in encryption, which the provider can decrypt), or strong + hard (LUKS2 / VeraCrypt with their own learning curve, no hardware-key story, no post-quantum option).

LUKSbox takes a different position:

A single drop-in vault file you can put anywhere - including on a cloud provider you don't fully trust - protected by the physical YubiKey on your keychain (or Titan, Nitrokey, Windows Hello, etc.) plus optional post-quantum keyslots, with the same tool and the same .lbx file working the same way on Linux, macOS, and Windows.

The unique value is **simplicity + hardware-backed authentication

• portable across every OS + open about its security**. You stay in control of your encryption keys; the cloud sees only opaque encrypted bytes.

Cloud-storage scenario this is built for

You want to store sensitive files (financial records, legal documents, source code, medical history, personal photos) in a cloud bucket / sync service without trusting that provider with plaintext. Today's options:

The cloud holds the encrypted blob; you hold the YubiKey and the optional .kyber seed file. Loss of the cloud = loss of an opaque ciphertext. Loss of the YubiKey = use your backup passphrase or a second enrolled YubiKey. The cloud provider cannot read your data even if they want to.

Side-by-side: what makes LUKSbox unique

The two columns where only LUKSbox is green below are the specific gaps it fills.

The simplicity argument

Look at what it takes to set up "encrypted folder backed up to the cloud + unlockable from my YubiKey" with each tool:

With LUKSbox

luksbox create my-cloud.lbx --kind fido2
# Touch your YubiKey twice. Done.

# Sync my-cloud.lbx with whatever cloud tool you use.
# Mount when you need to read/write:
mkdir /tmp/v && luksbox mount my-cloud.lbx /tmp/v
# Touch YubiKey once. Use /tmp/v as a normal folder.
luksbox umount /tmp/v

Three commands. One tool. One physical key. Same on Linux, macOS, Windows.

With LUKS2 + cryptsetup

# Linux only. Won't work on your MacBook or your kid's Windows
# laptop. You'd need:
sudo dd if=/dev/zero of=my-cloud.img bs=1M count=1024
sudo cryptsetup luksFormat my-cloud.img
sudo systemd-cryptenroll --fido2-device=auto my-cloud.img
# Now hope the cloud sync tool doesn't choke on a 1 GB block
# device. Spoiler: most do. LUKS2 wants kernel block-device
# semantics.

With VeraCrypt

GUI dialog: pick which of 12 cipher cascades, which of 6 hashes, which PIM value. Hardware key not supported (no FIDO2). Type a passphrase. Nice GUI though.

With age

# age encrypts streams, not folders. To back up a folder:
tar c folder | age -r age1...recipient... > folder.tar.age
# Want to add one new file?
age -d folder.tar.age | tar xv
# add file
tar c folder | age -r age1...recipient... > folder.tar.age
# Repeat per change. No mounted-folder UX.

LUKSbox isn't the strongest tool in any single dimension. LUKS2 is more battle-tested for full-disk; VeraCrypt has more cipher options; age is faster for single-file backups. LUKSbox is the tool that gets the cloud-storage + hardware-key + portable- across-OSes use case right out of the box, with sensible defaults and a single binary.

When LUKSbox is the right tool

You'll like LUKSbox if:

• YES You want a YubiKey / Titan / Nitrokey / Windows Hello to be the primary unlock method
• YES You want the same vault file to work on Linux, macOS, AND Windows
• YES You want to drop encrypted data in Dropbox / iCloud / S3 / etc. without the provider being able to read it
• YES You want post-quantum-resistant keyslots as an option for long-term archival
• YES You want a mounted-folder UX (cd into it, edit files normally) rather than a per-file encrypt-and-replace flow
• YES You want a CLI for scripts AND a GUI for non-technical users covering the same vault format
• YES You want a deniable vault format whose on-disk bytes are indistinguishable from random output (since v0.2); two-passphrase hidden / nested volumes are planned for v1.0

When LUKSbox is the wrong tool

To round out the comparison, here are honest cases where LUKSbox is the WRONG choice:

Detailed comparisons

vs LUKS2 / cryptsetup

LUKS2 is the gold standard for Linux block-device encryption. Older, more widely deployed, kernel-backed. Right choice for system partitions / data-at-rest on Linux servers.

LUKSbox is userspace, file-container only, cross-platform. Can't replace LUKS2 for full-disk encryption. CAN replace LUKS2 + a separate FIDO2 layer + a separate cross-platform tool:

vs VeraCrypt

VeraCrypt is the established cross-platform vault tool. It forked from TrueCrypt 7.1a after TrueCrypt's abrupt May-2014 shutdown (developers anonymous, no clear explanation; the OCAP audit Phase 1 and Phase 2 later found 4 vulnerabilities total - 1 high, 3 medium - none catastrophic). VeraCrypt has been around since 2013 and has had two third-party audits:

• Quarkslab/OSTIF (Oct 2016), 23 findings: AES cache-timing marked "Not Fixed" High severity, plus various unauthenticated-ciphertext + GOST + zlib issues. See our internal gap analysis vs Quarkslab/OSTIF and BSI/Fraunhofer (available on request to [email protected]) in the source repository.
• BSI / Fraunhofer SIT (2020), the German Federal Office for Information Security: year-long evaluation. Verdict: "we cannot recommend VeraCrypt for sensitive data and persons or applications with high security requirements." (Source PDF)

BSI's specific concerns (verbatim from the executive summary):

• No authenticity / integrity protection: "Authenticity and integrity, however, are not protected" - VeraCrypt uses XTS, not AEAD; ciphertext bit-flips don't trigger any verification failure.
• Outdated KDF + hash (BSI 2020 quote, partially addressed since): "VeraCrypt still uses the outdated and deprecated RIPEMD-160 hash algorithm". BSI recommends "a state-of-the-art key derivation function". VeraCrypt 1.26.x removed RIPEMD-160 and v1.26.27 (Sep 2025) added Argon2id support, but PBKDF2 with SHA-512 remains the default; Argon2id is opt-in and the Windows build was the first to ship it. By contrast LUKSbox has used Argon2id as the default and only KDF since v0.1.
• Single-developer maintenance risk: "the project is still mostly driven by a single developer rather than a development team" + "did not follow an elaborated software-development cycle with acknowledged best practices for software engineering, for instance, quality gates, peer reviews, and documentation of code changes".
• Inherited TrueCrypt code quality: "the code base still mainly consists of code from the TrueCrypt project that has been repeatedly criticised for its poor coding style".
• Mounted-volume attack surface: "A mounted VeraCrypt volume is exposed to a multitude of attack vectors including vulnerabilities of the host system".

Aside: about veramount and YubiKey-via-VeraCrypt wrappers

A reasonable counter-question: "but I can use a YubiKey with VeraCrypt via the veramount project, right?" Yes, with significant caveats worth understanding:

• It's a third-party shell-script wrapper, not native VeraCrypt support. Linux-only (tested on Lubuntu 19.04), root required, and multi-step manual setup (GPG keygen + YubiKey personalisation + pass password manager + script-constants editing).
• The YubiKey stores a 4096-bit RSA GPG key that decrypts a passphrase from pass. That decrypted passphrase is what's actually fed to VeraCrypt. The vault itself never sees the YubiKey; it sees a string.
• The wrap-KEK is still passphrase-derived. Whatever Argon2id / PBKDF2 cost VeraCrypt is configured for, that's the work an offline attacker with the .lbx would do. The YubiKey controls who can read the passphrase from disk, not how strong the wrap is once the passphrase is known.

LUKSbox's FIDO2 keyslot kind uses CTAP2 hmac-secret (the same mechanism systemd-cryptenroll --fido2-device= and Bitwarden's WebAuthn PRF rely on). The wrap-KEK is derived inside the authenticator from a per-vault salt and a device-secret that never leaves the YubiKey. Even with the .lbx and the user's passphrase (in the wrap-mode variant), an attacker without the actual authenticator cannot brute-force the slot, because the device-secret is the only path to the KEK.

Pragmatic summary: veramount is a clever convenience wrapper for people already invested in VeraCrypt's GUI and habits. It is not a hardware-bound security boundary the way a CTAP2 hmac-secret slot is.

Aside: the TPM disagreement

VeraCrypt's official FAQ is unusually direct on TPM:

"The only thing that TPM is almost guaranteed to provide is a false sense of security." "TPM is actually redundant (and implementing redundant features is usually a way to create so-called bloatware)."

Their argument: a privileged attacker with admin / physical access can keylog the user, dump RAM, or install hardware bugs, so TPM cannot save you in that scenario.

That's true, but it answers a question nobody asked. TPM is not designed to defend against a compromised host; it defends against offline, cross-machine attacks against the vault file. Two common scenarios where this matters:

LUKSbox takes the opposite design call: TPM is one keyslot kind among several, not a security cure-all. The variants we ship (tpm2, tpm2-pin, tpm2-fido2, plus four hybrid-PQ-TPM combinations) let users compose protection. A tpm2-fido2 slot requires both the local TPM and a connected FIDO2 authenticator; a hybrid-pq-tpm2-fido2 slot adds an ML-KEM-768 / 1024 PQ half on top of that. Even a TPM compromise alone does not unlock those slots. That layered defense is precisely what VeraCrypt rules out by refusing to add TPM at all.

LUKSbox shares VeraCrypt's "single encrypted file" model but takes different design choices on most of the points BSI raised:

Pick VeraCrypt if you need hidden volumes today (LUKSbox's equivalent is on the v1.0 roadmap; the v0.2 deniable-vault format gets you random-looking on-disk bytes but not the "two passphrases unlock two distinct vaults" hidden-volume property), or you have a long-running existing VeraCrypt deployment you'd rather not migrate.

Pick LUKSbox if you want what BSI 2020 said VeraCrypt isn't suitable for: protecting sensitive data with modern authenticity guarantees, hardware-key support, post-quantum options, and active multi-author maintenance.

vs age

age is a streaming file-encryption tool. Different problem domain: age encrypts single files or streams; LUKSbox manages a mountable container with multiple files, in-place edits, per-chunk integrity, rollback detection.

Pick age for "encrypt one file for backup or transport." Pick LUKSbox for "encrypted folder I cd into" with hardware keys.

vs gocryptfs / Cryptomator

Both are FUSE-based "encrypted folder" tools. Closer in shape to LUKSbox than VeraCrypt or age.

Pick gocryptfs / Cryptomator if you need per-file delta sync in Dropbox/Drive/etc. (their per-file design plays much better with cloud-sync clients than LUKSbox's single-container design).

Pick LUKSbox if you want one file (easier to move, back up, sneakernet, archive) plus hardware-key + PQ support.

vs BitLocker / FileVault / native OS encryption

OS-native disk encryption (BitLocker on Windows, FileVault on macOS) is the right tool for full-system encryption. Deeply integrated, kernel-backed, uses hardware acceleration.

LUKSbox is NOT a replacement for these. It's a portable container layer that works ON TOP of OS encryption.

Use both: BitLocker / FileVault for the system, LUKSbox for the specific high-value vaults you want to move between machines or keep in the cloud.

Pairings: LUKSbox + ...

Most "pick one tool" comparisons are misleading because the right answer is often a layered stack, full-disk for the system, a container tool for portable vaults, plus a streaming tool for single-file transports. LUKSbox is built to layer on top of OS encryption, not replace it. The pairings below cover the cases we see most often.

LUKSbox + LUKS2 / BitLocker / FileVault (system layer)

OS FDE protects you when the device is off and stolen. It does nothing for files copied off the running system, files synced to the cloud, or files moved to another machine. LUKSbox plugs exactly those gaps. The two systems are non-overlapping; turn on both.

LUKSbox + cloud sync (Dropbox, Drive, iCloud, S3, Backblaze, ...)

Trade-off worth knowing: LUKSbox is a single-file container, so any change re-uploads the whole .lbx. Fine for vaults you change infrequently (archives, password DBs, recovery codes); painful for working sets you edit hourly. For the latter case use Cryptomator or gocryptfs (per-file encryption that plays well with delta sync) and accept that they don't have FIDO2 / TPM / hybrid PQ.

LUKSbox + age (transport layer)

age is the thing you reach for when LUKSbox is the wrong shape (you want to send one file, not maintain a vault). Both are pure Rust, both use modern AEAD, both interoperate cleanly: extract the file from the LUKSbox vault, age-encrypt it for the recipient, send.

LUKSbox + a hardware key (FIDO2 / TPM / hybrid PQ)

For the device-specific comparison (price, audit history, side-channel posture, NFC support, what to avoid), see FIDO2 keyslots, Choosing a hardware key.

LUKSbox + the local TPM 2.0 (Linux)

LUKSbox + a separate .kyber seed (post-quantum)

The two halves are independent: if either primitive breaks, the other still protects the vault. Storing the seed next to the vault defeats the purpose; the standard pattern is "vault in cloud / NAS, seed on USB stick or different cloud account."

In one sentence

LUKSbox is for the user who has a YubiKey (or wants one), wants to keep sensitive data in the cloud without trusting the cloud, wants their encrypted vault to work the same way on every machine they own, and wants the option to defend against a future quantum adversary - all in a single CLI / GUI / mounted-drive tool with sensible defaults.

If that's you, start with the Quickstart. If not, one of the tools above is probably a better fit, and the comparison above will help you pick.