Reliable Encrypted Containers with FIDO2 and Post-Quantum Cryptography Support

Cloud providers love to repeat the phrase "your data is encrypted at rest." It sounds reassuring, until you remember who holds the keys to that encryption. If the hosting provider has the keys, then any regulator request, internal leak, or compromised access token can open your files to outsiders.

To avoid relying on trust in someone else's service, data is encrypted client-side before being sent over the network. Tools like VeraCrypt, gocryptfs, or age exist for this, but each has its trade-offs: outdated formats, lack of hardware key support, or complications when mounting the container as a regular disk.

I recently came across LUKSbox, a project written in Rust. It's a tool for creating encrypted file containers that takes the best ideas from the LUKS2 world but adapts them for cloud storage, USB drives, and modern authentication methods.

---

What's Inside the Container

The core concept is straightforward: all data is packed into a single file .lbx. To an outside observer or cloud drive, this file looks like random noise with no obvious headers or metadata, provided the header is stored in a separate file.

At the same time, the container mounts in the operating system as a regular disk via FUSE (on Linux and macOS) or WinFsp (on Windows). You work with it just like a regular flash drive.

The project's main goal, as the authors describe it, is creating a portable secure copy. You upload .lbx to S3, Dropbox, or a shared network drive and rest easy: the host is physically unable to read the contents.

---

Unlock Methods and Quantum Computer Protection

Typically, encrypted storage requires a password. LUKSbox has passwords too, hashed via Argon2id with serious default parameters, but the developers went further and added slots for hardware keys.

Here are the supported options for unlocking the storage:

1. FIDO2 authenticators. You can bind a YubiKey, Nitrokey, or Google Titan via the HMAC-secret protocol. Without physically touching the key, the container won't open.
2. TPM 2.0. Binding to your motherboard's hardware chip on Linux and Windows. Convenient if the container should only open on your workstation.
3. Post-quantum hybrid mode. Protection against the "harvest now, decrypt later on a quantum computer" scenario. LUKSbox can combine classical algorithms with the ML-KEM algorithm (FIPS 203, formerly Kyber). A separate key file .kyber is created for this, which you can keep separately from the container.

None of these slots encrypt files directly. They wrap the Master Volume Key. Upon successful validation of any slot, the master key is decrypted, and keys for metadata, file blocks, and integrity verification are derived from it via HKDF-SHA256.

+-------------------------------------------------------------+
| Пароль / FIDO2 / TPM 2.0 / ML-KEM (.kyber)                 |
+------------------------------+------------------------------+
                               |
                               v
               +-------------------------------+
               | Master Volume Key (MVK)       |
               +---------------+---------------+
                               |
         +---------------------+---------------------+
         v                     v                     v
+-----------------+   +-----------------+   +-----------------+
| Header HMAC Key |   | Metadata Key    |   | Per-file Keys   |
+-----------------+   +-----------------+   +-----------------+

---

Security at the Detail Level

The repository pleasantly surprises with attention to details that many developers overlook.

By default, AES-256-GCM-SIV is used for block encryption. The SIV addition provides resistance to nonce reuse, which is useful during frequent overwrites. You can also choose ChaCha20-Poly1305 or standard AES-256-GCM.

A few interesting findings from the source code:

• Block substitution protection. Each encrypted chunk of a file is equipped with additional authenticated data (AAD), including the file ID, block index, and generation counter. A cloud-based attacker won't be able to silently replace a new block with an older version or swap pieces around.
• Memory cleanup. On Linux, the memfd_secret system call excludes the master key from kernel memory dumps and hibernation images. On other systems, a combination of memory locking and buffer zeroing via Zeroize traits is used.
• Rollback attack protection. An optional sidecar file .anchor stores a signed change counter. If a provider rolls back the entire container to an older version, the program will notice.
• Separate header. If you move the header to a .hdr file, the main container .lbx becomes a byte array with no signatures.

---

Quick Start

The project is written in Rust, so you can build it from source the standard cargo build way. Pre-built packages .deb, .rpm, Windows installers, and macOS bundles are available for most platforms.

You can manage containers three ways: via CLI, an interactive TUI wizard, or a graphical interface built on egui.

Creating a regular container and mounting it:

# Создаем хранилище с настройками по умолчанию
luksbox create my-vault.lbx

# Монтируем как директорию в Linux/macOS
luksbox mount my-vault.lbx /mnt/vault

# Или в отдельный диск в Windows
luksbox mount my-vault.lbx Z:

Adding a FIDO2 hardware key to an existing container:

luksbox enroll my-vault.lbx --kind fido2

Creating a post-quantum container with a hybrid key on a separate flash drive:

luksbox create secure-data.lbx --kind hybrid-pq --pq-hybrid /media/usb/key.kyber

If you don't want to remember command-line flags, the luksbox wizard command starts a step-by-step dialog in the terminal.

---

Practical Scenarios

LUKSbox solves the problem of secure transport and remote storage. Here are situations where the project looks like a good fit:

1. Syncing via third-party clouds. You store your password database, personal keys, or work documents in a single .lbx file inside a Google Drive or Yandex Disk folder.
2. Backups on external servers. A backup script mounts the container, puts fresh dumps in, and unmounts the disk.
3. Sharing secret archives. Sending files to a colleague with a requirement for physical confirmation via a hardware token.

---

Current Project Status

The project is in pre-1.0 stage. Container format v3 is already frozen, fuzzing is configured in the repository via libFuzzer and AFL++ with millions of iterations. Fourteen internal security audit rounds have been completed, although an independent third-party audit is still ahead.

The authors honestly warn: an encrypted container is a single point of failure. If the file gets corrupted or all keys are lost, the data is unrecoverable. Therefore, LUKSbox is designed for protected portable copies, not as the sole storage location for critically important files.

If you need a modern cross-platform encryption tool with FIDO2 support and a post-quantum future-proofing, the repository is definitely worth looking into. The source code is released under the Apache-2.0 license.