Managing keyslots

Add / revoke / rotate keyslots, multi-device setup, MVK rotation.

The Keyslots view is where you add backup keys, revoke compromised ones, and rotate the master volume key. Reach it via the toolbar button Keyslots in the Browser view.

The slot table

A LUKSbox vault holds up to 8 keyslots. Each slot is independent: any active slot can unlock the vault, revoking one doesn't affect the others.

Add a keyslot

Click Add keyslot. A modal opens with the same kind picker as the Create form, then walks the flow:

1. Pick the new keyslot kind (any of the 7 slot kinds)
2. Provide whatever inputs that kind needs (passphrase, FIDO2 touch, .kyber path, etc.)
3. The GUI authenticates with an EXISTING keyslot first (recovers the MVK), then derives the new wrap KEK and stores the new slot
4. On success, the slot table refreshes; the new slot appears

This is the standard way to add a backup. Best practice for high-value vaults:

• Slot 0: Passphrase (paper-backed)
• Slot 1: FIDO2 daily-use device (your YubiKey 5)
• Slot 2: FIDO2 backup device (kept in a safe deposit box)
• Slot 3: Optional emergency passphrase

Revoke a keyslot

Click a slot row, then click Revoke. A confirmation modal explains exactly what happens:

• Zeroes the slot's wrapped MVK ciphertext + tag + nonce + KDF salt + cred_id (if FIDO2)
• The slot becomes Empty
• The remaining slots are untouched
• The MVK is NOT rotated - if an attacker has previously extracted the MVK from this vault, they still have it after revocation

If you suspect a keyslot was actively compromised (someone copied your .lbx AND has your YubiKey AND your PIN, say), follow the revoke with Rotate MVK below. That generates a fresh MVK and re-encrypts every chunk under it.

The GUI refuses to revoke the last remaining keyslot (would lock you out of the vault).

Rotate the MVK

Click Rotate MVK. This is the most invasive operation; the confirmation modal explains the cost. What rotation does:

1. Generate a fresh random MVK (OsRng, 32 bytes)
2. Re-encrypt EVERY file chunk under keys derived from the new MVK
3. Re-wrap EVERY active keyslot under the new MVK
4. Re-derive the header HMAC + the anchor sidecar's HMAC
5. Atomically commit (rename a .lbx.rotate-tmp over the original)
6. Update the GUI: slot details refresh, "rotated at HH:MM" badge appears

After rotation, any previously-extracted MVK is useless against the vault. Use this:

• After revoking a compromised slot
• On a calendar (annual rotation policy)
• After a security incident in your org
• Before publishing a vault to long-term cold storage

The GUI shows a real-time progress bar during rotation. The vault remains usable after a successful rotation; on a crash mid-rotation the original vault stays intact thanks to the <vault>.rotating temp-file commit protocol.

Inspect a keyslot

Click a slot row + Inspect for the full per-slot detail dialog, useful for:

• Verifying which YubiKey is bound to a slot (cred_id length matches the device's typical output)
• Confirming the KDF parameters match what you set at create
• Audit-trail evidence ("yes, slot 1 uses V3 layout")

Tips

• Always have at least 2 keyslots for any vault you care about. Single-slot vaults are one device-loss away from unrecoverable.
• Revoke + rotate after device loss, not just one or the other.
• The slot index isn't a security property - slot 5 is no more or less secure than slot 0. Indexes are just labels.
• You can mix kinds freely - passphrase + FIDO2 + hybrid-PQ all in the same vault, in any combination.

Next

• Browser view (file management) ->
• Panic mode ->