No custody of disk keys

Panocrypt does not escrow customer disk keys. The server participates in a blinded recovery exchange, but the client reconstructs the binding secret locally from Panocrypt’s response and the encrypted metadata stored on the machine.

Plainly: the unlock key is born on the machine, wrapped on the machine, stored on the machine, and never handed to Panocrypt. Panocrypt participates when policy allows, but it does not hold a reusable disk secret to hand back later.

The short version

Panocrypt is one side of a McCallum-Relyea exchange. During binding, the machine creates and wraps its own unlock material. During boot, Panocrypt returns its side of a blinded recovery exchange only when policy allows the request.

The managed unlock path is split. The machine keeps the encrypted unlock metadata. Panocrypt participates in recovery only when policy allows.

Where the unlock key lives

During binding, Clevis gets Panocrypt’s public exchange material for this device. On the host, Clevis creates a high-entropy local unlock key, adds it to one LUKS keyslot, and wraps the local unlock metadata as a JSON Web Encryption (JWE) object.

To wrap it, Clevis combines Panocrypt’s public exchange material with fresh client-side private material and derives local wrapping material. After the encrypted metadata is stored locally, Clevis discards both the derived wrapping material and the private material it would need to recreate that wrapping material alone.

Panocrypt never receives the LUKS passphrase, the local unlock key, disk plaintext, or a reusable disk secret.

What happens at boot

At boot, the distribution’s native Clevis code reads the local encrypted unlock metadata and asks Panocrypt to participate in a blinded elliptic-curve recovery exchange. The request carries blinded cryptographic material and operational context, not a disk key.

Panocrypt evaluates policy before it participates. If policy allows the request, Panocrypt returns its side of the blinded McCallum-Relyea recovery exchange.

That response is not a disk key. It is not the local unlock key. It is not useful by itself.

The local encrypted metadata is not enough by itself either. Clevis needs both sides of the unlock path:

• The local encrypted unlock metadata stored with the machine.
• Panocrypt’s policy-approved recovery response for this request.

Together, those let Clevis reconstruct the wrapping material locally, unwrap the local unlock key, and open the Panocrypt-bound LUKS keyslot.

Why TLS still matters

Network-bound disk encryption does not work by downloading a disk key. The McCallum-Relyea exchange uses public or blinded cryptographic material, and the client reconstructs the binding secret locally.

Panocrypt still uses TLS because managed unlock happens over the public internet and the request carries organization identity, device identity, and policy context. TLS protects the HTTP request context and server authenticity. The blinded recovery exchange is why Panocrypt can participate without receiving the local unlock key.

What Panocrypt stores

• Panocrypt’s side of the recovery exchange and the service records needed to operate it.
• Organization records, device state, unlock policy, allowed sources, lifecycle state, and unlock history.
• Administrative user and account records.

What Panocrypt never receives

• Customer content keys.
• LUKS passphrases.
• Local unlock keys.
• Disk plaintext.
• Customer recovery passphrases.
• The local binding secret reconstructed during unlock.
• A universal emergency recovery key.

If policy denies unlock

Panocrypt policy controls whether Panocrypt will participate in a future managed unlock for a device. The decision can account for lifecycle state, source policy, direct allowed IPs, Network Access lists, and manual approval requirements.

If policy denies the request, Panocrypt does not participate in the recovery exchange. The disk remains locked unless the operator uses customer-held recovery material or another independent local unlock path.

If Panocrypt is unavailable

Panocrypt availability matters for Panocrypt-managed unlock. If the service cannot be reached during boot, Panocrypt cannot participate in that managed unlock request.

That is an availability dependency, not key custody. Panocrypt still does not hold the LUKS passphrase, local unlock key, disk plaintext, customer recovery passphrase, or a universal emergency recovery key.

The break-glass path stays local: use a customer-held LUKS recovery passphrase, another independent LUKS keyslot, provider console or rescue access, or another unlock path you control.

Trust boundary

Full-disk encryption protects data at rest. Panocrypt should not be treated as runtime compromise prevention, remote wipe, a cloud KMS replacement, or a data recovery service.

Customers remain responsible for preserving local recovery material, securing running hosts, validating platform support, and deciding whether the evidence surfaces satisfy their internal policy.

Remove the managed unlock path

Panocrypt binding uses one local LUKS keyslot through Clevis. Removing the Panocrypt-bound Clevis keyslot removes that managed unlock path.

Removing the local binding does not delete Panocrypt audit history or device records. It does not remove independent local recovery keyslots, lock a running host, remove keys from memory, or wipe a disk.

Use Remove Panocrypt from a LUKS device for the removal commands and verification path.

What you should keep

Keep these outside Panocrypt:

• LUKS recovery passphrases.
• LUKS header backups where your operating procedures require them.
• Provider console or KVM access for root-disk recovery.
• Provider snapshots or backups if your recovery plan depends on them.
• Internal rollout evidence and approval records that your policy requires.

Those materials keep recovery under customer control. Panocrypt can allow, deny, and evidence future managed unlock decisions, but it is not a key escrow service.

For the full end-to-end managed unlock walkthrough, read Automatic unlocks. For the local keyslot model, read LUKS keyslots.