LUKS keyslots and Panocrypt binding

LUKS can have multiple independent unlock paths. That is what makes Panocrypt-managed unlock easy to reason about.

Panocrypt does not become the owner of the disk. A Panocrypt binding adds one managed unlock path beside the customer-held recovery path you already control.

What a LUKS keyslot is

A LUKS device can be opened through more than one local unlock path. Each enabled keyslot can unlock access to the same encrypted volume. One slot might hold a recovery passphrase. Another slot might hold a Clevis network-bound unlock binding.

The exact number of keyslots depends on the LUKS version and device state. The important point is simpler: Panocrypt does not need to replace your recovery path. It uses one available slot.

Where Panocrypt fits

When you bind a LUKS device to Panocrypt with Clevis:

1. Clevis creates a local unlock key.
2. Clevis adds that local unlock key to one LUKS keyslot.
3. Clevis stores encrypted local unlock state with the LUKS header.
4. Panocrypt stores policy, device state, unlock history, and its side of the cryptographic relationship.

The local unlock key is created on the machine, wrapped on the machine, and stored with the machine’s LUKS state. Panocrypt never takes custody of that local unlock key.

After Clevis stores the encrypted unlock metadata locally, it discards the material it would need to recreate the wrapping key alone.

At unlock time, Panocrypt participates only when policy allows the request. The Panocrypt response is not a disk key. It is useful only with the device’s local encrypted state.

What stays yours

Keep a separate customer-held recovery path.

That usually means:

• A LUKS recovery passphrase you control.
• A LUKS header backup if your operating procedures require one.
• Provider console or KVM access before root-disk reboot tests.
• Any internal recovery records your policy requires.

Panocrypt does not store your recovery passphrase. If every local recovery path and keyslot is lost or removed, Panocrypt cannot recover the disk.

How to inspect the binding

Use your distro’s LUKS and Clevis tools.

export LUKS_DEVICE="/dev/disk/by-id/YOUR_DEVICE"

sudo clevis luks list -d "$LUKS_DEVICE"
sudo cryptsetup luksDump "$LUKS_DEVICE" | sed -n '/Keyslots:/,/Tokens:/p'

The Clevis output shows the slot or token used by the Panocrypt-bound Clevis tang binding. The cryptsetup output lets you inspect the enabled LUKS keyslots.

Removal model

Removing the Panocrypt-bound Clevis keyslot removes that managed unlock path. It does not remove independent local recovery keyslots. It does not delete Panocrypt audit history or device records. It does not lock a host that is already running.

The important trust boundary is this: after the local Panocrypt-bound keyslot/token is removed, Panocrypt’s side of the exchange is not enough to unlock the disk. The local LUKS state was always required.

For the recovery checks, commands, root-disk notes, and verification steps, use Remove Panocrypt from a LUKS device.