The mental model

  • Tang — a tiny stateless server. Holds asymmetric keys; performs ECDH key derivations on request. Doesn't authenticate clients (anyone on the LAN can ask).
  • Clevis — the client side. Wraps a LUKS slot's key in a way that requires Tang's cooperation to unwrap.
  • The crypto trick: the encrypted disk's key is recoverable only when both the local Clevis-bound material and the Tang server's keys are accessible. Move the drive somewhere Tang isn't reachable; can't decrypt.

This isn't "security through trusting the LAN to be safe." It's "the disk can't decrypt without Tang, and Tang is on a network the attacker doesn't have." Steal the drive and rack it elsewhere; Tang isn't reachable; no decrypt.

Set up the Tang server

Pick a small always-on machine on your LAN (Raspberry Pi, NAS, an existing server). Install Tang:

# Debian / Ubuntu
sudo apt install tang

# Enable the service (listens on port 80 by default)
sudo systemctl enable --now tangd.socket

# Or for a non-default port (e.g. 7500)
sudo cp /lib/systemd/system/tangd.socket /etc/systemd/system/
sudo sed -i 's/ListenStream=80/ListenStream=7500/' /etc/systemd/system/tangd.socket
sudo systemctl daemon-reload
sudo systemctl restart tangd.socket

Tang stores its keys in /var/db/tang/. First run auto-generates fresh keys.

Check the advertisement

# From any host, fetch Tang's public advertisement
curl http://tang.lab.example.com:7500/adv
# JSON blob with public keys + signature

For HA, run multiple Tang servers and bind to all of them; LUKS unlock succeeds if a configurable threshold are reachable.

Bind a LUKS slot to Tang (Clevis side)

On the encrypted host:

sudo apt install clevis clevis-luks clevis-systemd

# Bind a LUKS slot to a Tang server
sudo clevis luks bind -d /dev/sda3 tang '{"url": "http://tang.lab.example.com:7500"}'

# Will prompt for the existing LUKS passphrase (used to unwrap the key being re-wrapped)
# After this, a new LUKS slot is added containing the Tang-bound key

# Verify
sudo clevis luks list -d /dev/sda3
# 1: tang '{"url":"http://tang.lab.example.com:7500"}'

The original passphrase remains valid as a manual fallback; Clevis adds a new slot, doesn't remove the old.

Enable boot-time auto-unlock

# Add the clevis tools to the initramfs so boot can decrypt
sudo systemctl enable clevis-luks-askpass.path

# Regenerate initramfs
sudo dracut -f                              # Fedora / RHEL
sudo update-initramfs -u                    # Debian / Ubuntu

Reboot. If the network is up and Tang is reachable, the LUKS volume unlocks automatically; no passphrase prompt. If the network isn't up (Tang unreachable), the prompt for the manual passphrase appears.

SSS: require multiple Tangs (threshold)

For "require 2 of 3 Tang servers to be reachable" patterns:

sudo clevis luks bind -d /dev/sda3 sss '{
  "t": 2,
  "pins": {
    "tang": [
      { "url": "http://tang-1.lab.example.com" },
      { "url": "http://tang-2.lab.example.com" },
      { "url": "http://tang-3.lab.example.com" }
    ]
  }
}'

Now the disk unlocks only if at least 2 of the 3 Tangs respond. Useful for higher-redundancy + tamper-resistance (one Tang's compromise alone isn't enough).

Threat model: what NBDE protects against

  • Stolen disk / laptop powered up away from LAN. Tang unreachable → no decrypt → data confidential.
  • Disposed-of disk that's not securely wiped. Whoever finds it can't decrypt without Tang.
  • Booted hardware moved to a different rack / building / country. Same as above.

What NBDE doesn't protect against

  • Attacker on the LAN. Anyone on your network can ask Tang to unwrap. Trust your LAN segmentation; or use TPM-backed Clevis to require the host's TPM to participate.
  • Attacker who steals the whole rack including Tang. They have everything they need to unlock. NBDE is about geographic / network locality, not theft of the whole environment.
  • Running attacker on the booted machine. Once the machine is decrypted and running, NBDE doesn't help. Use LUKS suspend / re-locking for paranoid setups.
  • Cold-boot / DMA attacks. Memory has the key once decrypted; physical-access threats remain.

TPM2-bound Clevis (defense in depth)

For higher assurance, combine Tang with TPM2 (only the original host's TPM can participate):

sudo apt install clevis-tpm2

# Bind to both TPM2 + Tang via SSS
sudo clevis luks bind -d /dev/sda3 sss '{
  "t": 2,
  "pins": {
    "tpm2": [{}],
    "tang": [{"url": "http://tang.lab.example.com:7500"}]
  }
}'

Now unlock requires the same TPM (so the disk can't be moved to other hardware) AND Tang reachable (so it can't be moved off-LAN). Belt + suspenders.

Key rotation

# On the Tang server: rotate keys
sudo tang-show-keys 7500     # current keys

# Generate new keys, mark old as rotated (kept for backward-compat until you unbind)
cd /var/db/tang
sudo /usr/libexec/tangd-keygen .
sudo /usr/libexec/tangd-update . cache

# On each client: re-bind to pick up new key material
sudo clevis luks regen -d /dev/sda3 -s 1

Rotate Tang's keys periodically (every 6-12 months); clients re-bind. Doesn't require a re-encrypt of the LUKS volume — only the wrapping key changes.

Backups still matter

NBDE protects confidentiality; it doesn't replace backups. Keep:

  • A copy of Tang's /var/db/tang/ in your offsite backup (so a destroyed Tang server can be rebuilt with the same keys).
  • The original LUKS passphrase (in a password manager) so you can manually unlock if Tang is down for an extended period.

When NBDE is overkill

  • For a single home machine that always boots interactively, plain LUKS with a passphrase is simpler.
  • For cloud VMs, NBDE doesn't make sense (your "LAN" is the cloud provider's network).
  • For Mac / Windows machines, use platform-native FileVault / BitLocker; NBDE is Linux-only.

For Linux homelab + datacenter racks with multiple encrypted machines that need to boot unattended, Tang + Clevis is the canonical pattern in 2026.