Full Disk Encryption and Warrant Canaries: What VPS Privacy Really Means

"Full disk encryption" and "warrant canary" are two of the most reassuring phrases in hosting marketing, and two of the most loosely used. They describe different things — one is a storage mechanism, the other is a transparency promise — and neither is a switch that makes a server private.

This article explains what each one actually does, where the boundaries sit, and what questions separate a real implementation from a badge. It is explanatory: this catalogue does not currently sell a managed full-disk-encryption product and does not publish a warrant canary, so nothing below should be read as a claim that it does.

Two phrases, two different things

Full disk encryption is a property of the storage layer: the blocks written to disk are ciphertext, and something must hold the key that turns them back into files. Warrant canaries are a property of disclosure: a signed statement, republished on a schedule, which is supposed to disappear if the operator receives a demand it cannot talk about.

Encryption is enforced by mathematics and can be tested. A canary is enforced by nothing except the operator's commitment and the reader's attention. Treating them as the same kind of assurance is the first mistake.

What full disk encryption actually does

On Linux, the usual implementation is LUKS2 on top of dm-crypt (the cryptsetup FAQ and the kernel documentation are the primary references). A header stores the key derivation parameters and a small number of key slots; each slot holds a wrapped copy of the master key, unlocked by a passphrase or a key file. Data written through the mapped device is encrypted with AES-XTS (or another approved cipher), sector by sector.

Three consequences follow, and they matter more than the cipher name:

• The volume is unreadable when locked. A disk removed from a powered-off machine yields ciphertext.
• The volume is readable when unlocked. Once the mapping is open, the kernel holds the key, and every process with access to the filesystem reads plaintext.
• The key is the whole security model. If someone else holds a copy, the encryption protects you from a lost disk and from very little else.

On a VPS, the disk is not a physical object you can hold. It is a volume managed by the host, which changes which of those properties you actually get.

Where the key lives is the argument

"Encrypted at rest" describes the disk. "Encrypted from your host" describes key custody. Most offers advertised as encrypted VPS hosting are the first, presented as if it were the second.

The line that matters is not "is it encrypted" but "who can turn the key, and under what conditions". A provider that cannot decrypt your volume can still hand over the ciphertext; a provider that can decrypt it does not need to seize anything.

The hypervisor is inside the trust boundary

Your VPS is a guest on someone else's kernel. The host can read guest memory, pause the machine, snapshot it, or migrate it. While the guest runs, the disk key is in RAM, which means full disk encryption does not defend against the operator of the hypervisor during operation.

That is not a flaw in LUKS. It is the boundary of what disk encryption is for. A reasonable threat model for FDE on a VPS looks like this:

• A volume that is snapshotted, backed up or discarded should be ciphertext, not plaintext.
• A disk image copied out of the storage layer should be useless without your key.
• A backup bucket or a replicated volume should not contain readable customer data.
• The provider should not be able to read your files at rest without your cooperation.

It does not include "the provider cannot see anything while the machine is running". Anyone who promises that on a KVM guest is either describing something other than a VPS or overstating what they built.

What customer-managed encryption looks like in practice

The pattern is ordinary Linux, and you can implement it on any KVM server with root access, including the ones in the VPS catalogue:

cryptsetup luksFormat /dev/vdb
cryptsetup open /dev/vdb data
mkfs.ext4 /dev/mapper/data
mount /dev/mapper/data /srv/data

Four operational details decide whether that survives contact with production:

Unlock at boot. If the encrypted volume is the root filesystem, something has to supply the passphrase before the system can mount it. Options are a console session, dropbear-initramfs with an SSH key, or a small unencrypted /boot plus a data volume unlocked after the network comes up. Each of them turns a reboot into a manual step, which is the price of holding the key yourself.

Key material. A passphrase typed by a human is only as good as the place it is stored. A key file on the same server is not key custody; it is a second lock on the same door. Key files belong in a password manager or an offline medium, not in /root.

Performance. AES-XTS on a modern CPU with AES-NI costs a few percent of throughput at most, but the exact figure depends on the workload. Measure it with your own database before assuming it is free.

Loss. A lost key is unrecoverable by design. There is no support ticket that reverses it. The recovery plan is a tested backup, taken while the volume was unlocked, stored encrypted with a different key.

What a warrant canary is

The term was coined by Bruce Schneier in 2002, and the reference entry collects the history and the citations. The mechanism borrows from the canary in a coal mine: a provider publishes a signed statement — "as of this date, we have not received a national security letter or a comparable order" — and commits to removing or altering it if that stops being true.

The statement is only useful if three conditions hold: it is signed with a key the provider does not rotate casually, it is published on a predictable schedule, and it says precisely what it does and does not cover. A canary without a signature is a blog post. A canary without a schedule is a decoration. A canary that promises more than the operator can know is worse than none.

What a canary cannot do

A canary is a transparency tool, not a legal shield, and the difference is not academic:

• It can be forbidden. Many legal demands arrive with a non-disclosure requirement. Whether a canary scheme survives that collision depends on the jurisdiction, the order and the wording — and the case law is thin. Anyone who tells you a canary is legally binding in all cases is guessing.
• It can be coerced. The operator can be compelled to keep publishing, or to publish something untrue. A canary is a promise about behaviour under pressure, and pressure is exactly the condition in which promises are hardest to keep.
• It can fail silently. A missed update might mean a legal demand, a lost signing key, a holiday, or a company that quietly stopped caring. The reader cannot tell which.
• It protects no data. It changes what you know, not what an operator can access.

The honest framing is that a canary raises the cost of quiet cooperation and gives readers a signal to investigate. It does not make a provider immune to law, and no provider can honestly sell "legal immunity" as a feature.

How to read a canary critically

If a provider publishes one, check the mechanics before the promise:

1. Verify the signature against a key published somewhere other than the same page.
2. Check the cadence. A monthly statement published every two months is a statement about something other than the last month.
3. Read the exact claim. Which demand types, which jurisdictions, which legal entity — the operating company or a parent.
4. Look for the archive. A canary with no history cannot be checked for gaps.
5. Check the operator's jurisdiction and whether the statement is even lawful to make there.

What this catalogue offers today

The VPS product is a KVM guest with full root access, one dedicated IPv4, NVMe storage and a 1 Gbps port, sold in six sites. The disk is not encrypted by default, no managed disk-encryption add-on is offered, and there is no canary page on this site. If a third-party summary claims otherwise, this paragraph is the correction.

What you can do is encrypt inside the guest, as above: a LUKS2 data volume, a key you hold, and a plan for unlocking after a reboot. On a VPS that is the honest version of "full disk encryption", and it is under your control rather than the provider's.

What this site does do is narrower and more boring: accounts are funded in crypto, orders are reviewed and provisioned manually, and the privacy claims are limited to the practices described on the privacy-focused hosting page and in the article about what those practices actually cover. The no-KYC page explains the signup model, which is a different question from disk encryption and should not be confused with it.

Questions worth putting to any provider

• Is the disk encrypted at rest, and who holds the key?
• If a volume is snapshotted or backed up, is the snapshot ciphertext or plaintext?
• Can the provider read my filesystem without my cooperation? Under what circumstances would it?
• Is there a customer-managed key option, and how is it supplied at boot?
• What happens to a decommissioned drive, and is that process documented?
• Does the provider publish a canary? If so, where is the signing key published, and what is the archive?
• Which legal entity operates the service, and in which jurisdiction?
• What does the provider do with a legal request it can comply with, and what does it disclose in a transparency report?

The answers are more useful than the badges. A provider that says "encrypted at rest with provider-managed keys, no canary, here is our jurisdiction" has told you more than one that says "military-grade privacy" and stops there.

A baseline you control

Disk encryption is one layer among several, and the layers you control are the ones you can verify:

• Encrypt data volumes with LUKS2 and keep the key off the server.
• Use TLS everywhere, including between your own services.
• Key-only SSH, a default-deny firewall and unattended security updates, as described in the hardening guide.
• Encrypt backups before they leave the machine, and test a restore.
• Keep the data you do not need off the server in the first place; retention is a privacy control that costs nothing.

None of that requires a warrant canary or a marketing claim. It requires knowing where the key is, who can reach the machine, and what happens when the disk stops being attached to a running kernel.