tapekey

Passphrase-driven AES-256 hardware encryption for LTO-4 and later tape drives.

tapekey loads an encryption key onto an LTO drive over the SCSI Security Protocol. Once a key is loaded, every read and write on that drive — by any tool — is transparently encrypted and decrypted at line rate in the drive's own hardware, until the key is cleared or the drive is power-cycled. No CPU cost, no re-encryption pass.

It does the same on-the-wire thing as stenc and IBM's ITDT, with one ergonomic difference: it can take a passphrase and derive the key for you, so there is no 64-character hex string to mind. It can still load and emit raw key files too, so it stays interoperable with every other tool in the ecosystem.

tapekey is part of a family of LTO-Tools and is also the hardware-encryption library used by opentome.

Status

Pre-1.0. The library API (Capabilities, ReadStatus, Load, Clear, DeriveKeyV1) is small and intended to be stable, but versions may still break before v1.0.0. The Linux SCSI path is the primary target; the FreeBSD path compiles and mirrors camcontrol(8) but is not yet validated on hardware — see Platforms.

Install

go install github.com/anyhow/tapekey/cmd/tapekey@latest

Or build from a checkout:

go build -o bin/tapekey ./cmd/tapekey

Go 1.26.3, pure Go, no CGO.

Usage

<device> is the SCSI generic node for the drive, e.g. /dev/sg2 (lsscsi -g lists them on Linux). Loading and clearing keys needs permission to open that node — usually root or membership in the right group.

# Load a key from a passphrase onto the drive:
tapekey load /dev/sg2

# Load a raw key file instead (stenc / IBM ITDT hex shape):
tapekey load --key-file drive.key /dev/sg2

# Inspect what the drive is doing and what it supports:
tapekey status /dev/sg2

# Turn encryption of for the drive:
tapekey clear /dev/sg2

Two offline helpers (no drive, no privilege):

# Mint a fresh random 256-bit key as a hex file:
tapekey generate --output drive.key

# Print the raw key a passphrase derives:
tapekey derive --output drive.key

For scripted runs, --passphrase-file FILE replaces the interactive prompt.

Passphrase vs. raw key

There are two ways to key a drive, and they serve two different needs:

• Passphrase (load with no --key-file) is for convenience and recovery. The key is derived from your passphrase with Argon2id and a fixed salt. There is no key file to store or lose — remember the passphrase and you can read the tape years from now. The trade-off is that this convenience layer is specific to tapekey's derivation (any other tool would need to reproduce the exact Argon2id parameters and salt below).

• Raw key (--key-file, generate, derive) is the universal interchange format. The drive's SCSI interface only ever accepts a raw 256-bit key; it knows nothing about passphrases. So a tape encrypted with a given raw key can be read by any tool that loads the same raw key — tapekey, stenc, IBM ITDT, a backup application.

Compatibility with stenc

If you normally use a passphrase but one day need to hand a tape to stenc, run tapekey derive once to get the raw hex key and feed that to the other tool:

tapekey derive --output drive.key
stenc -f /dev/nst0 -e on -k drive.key   # reads a tape tapekey wrote

So the passphrase is a convenience over a fully portable raw key.

KDF parameters (v1)

Documented so the passphrase derivation is reproducible by anyone who wants it:

Parameter	Value
Function	Argon2id
Salt label	tapekey-v1
Memory	1 GiB (1 << 20 KiB)
Time	4
Parallelism	4
Key length	32 bytes (256-bit)

These values are fixed: changing any of them is a format break and would require a new KDF version. opentome uses the identical label and parameters, so a tape keyed by one tool opens under the other.

Platforms

OS	Transport	State
Linux	SG_IO ioctl on /dev/sgN	Primary target
FreeBSD	CAMIOCOMMAND on /dev/passN	Compiles, UNTESTED
macOS	none	Compiles; every hardware op errors

The package builds on every Go target so it can be linked unconditionally; hardware operations return ErrUnsupported where there is no transport.

Security notes

• The fixed salt means tapekey's threat model is deliberately one tape, one user, one drive. It protects a lost or stolen cartridge, not a shared passphrase database. Choose a strong passphrase: it is the only secret.
• generate keys are random and cannot be re-derived — back up the key file.
• Key files are written 0600; tapekey warns if a --passphrase-file is group- or world-readable.
• A Load is verified after the fact: tapekey re-reads the drive's encryption status and confirms the key took before reporting success.

As a library

import "github.com/anyhow/tapekey/pkg/tapekey"

The public surface is intentionally tiny: Capabilities, ReadStatus, Load, Clear, and DeriveKeyV1, with SCSI sense conditions exposed as typed errors (ErrNotReady, ErrDataProtect, ErrIllegalRequest, ErrUnsupported).

Licence

MIT. See LICENSE.