# 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.

```sh
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](https://docs.panocrypt.com/trust/remove-panocrypt-binding/).