Tape drive encryption compared with encryption in the object.

Every LTO drive since generation 4 has an AES-256-GCM engine on its data path. Data is compressed, then encrypted, then written, at rated speed. The key arrives over the ordinary SCSI interface, is not kept in the drive, and is never written to the cartridge. What the LTO format does not do is manage keys. The LTO Program says so directly:

"Key management is not part of the LTO Ultrium drive specification."

So the keys come from somewhere else: from the writing application, from an external key manager over KMIP (the Key Management Interoperability Protocol), or from a store belonging to the library itself, such as the USB token in the chassis of HPE's MSL libraries. That choice is made by a product, not by the format. It does not affect how strong the encryption is. It affects what has to survive alongside the key for the key to be usable, which may be a running service, a vendor's product line, or nothing at all.

The drive's encryption engine, the key-management arrangement around it, and the product that holds the keys are three different things. Most of what follows concerns the second and third. The engine itself is not in question. The detailed comparison covers each arrangement, and the cartridge-level mechanics, in full.

The first difference is how often a key has to be handled. An object is written once, and everything after that recurs for as long as the collection is held: reading copies back, scrubbing for blocks that have begun to fail, rebuilding from parity, making further copies, migrating to newer media. Under drive encryption all of that passes through the decryption path, so a key has to be released to unattended jobs, for years, for work whose only purpose is to confirm that stored bytes have not changed. With encryption in the object, the ciphertext is what gets stored, checksummed, replicated, and repaired. A copy can be checked without being opened, and the key stays in custody. Every occasion a key is handled is an occasion it can leak, and this removes nearly all of them. It also separates custody from access: another institution can hold a copy, confirm it is intact, and repair it from parity without being able to see what it contains. Restoring an object, or verifying its contents against the manifest, still needs a key; routine upkeep does not.

The second is which drives can write which copies. Where encryption is applied by library policy, which is the usual arrangement, the policy binds to a partition and the drives serving it encrypt everything they write. A library holding both encrypted and unencrypted material then divides into encrypting and non-encrypting drives. In a small library that is a real cost: the drives cannot be pooled, so a given throughput needs more of them; wear falls unevenly; and losing one drive removes the ability to write one kind of copy until it is replaced. Nothing in the hardware requires the split, since encryption parameters are set per mount, but it is how the policy is normally deployed. With encryption in the object no drive is configured differently from another.

The third is that one ciphertext can travel to every medium. Drive encryption protects the copies on tape and nothing else, so a disk or off-site copy needs a second mechanism with its own key custody, and rebuilding one copy from another passes through plaintext on the host. Sealed in the object, the material is encrypted once and that byte string is copied unchanged to every medium.

We list that last deliberately, because we do not encrypt every copy and would not advise it. Encryption adds a way for readable data to become unreadable, and that risk is permanent while the threat it answers is usually circumstantial. It earns its place on the copy that leaves your control, and rarely anywhere else. But an archive that does want several encrypted copies on several media should not need several schemes to get them.

Property	Drive encryption	REM-ENCRYPT
Ciphertext begins	At the tape head	At ingest, before any storage is touched
What is protected	The cartridge	The object, on every medium it is copied to
Upkeep without a key	No	Storing, replicating, repairing from parity, scrubbing
Which drives write which copies	Policy usually binds encryption to a partition, so the drives divide by mode	Any drive writes any copy
Migrating to new media	Decrypt, cross the host in the clear, re-encrypt	Copy the bytes; no key is loaded
What the medium carries	A key identifier; some key managers also write a wrapped key to the cartridge	The whole envelope: cipher suites, wrapping, recipients, wrapped key
Needed to read a copy back	A compatible drive, the key, and a host that can send the SCSI security commands	The two specifications, a conforming implementation, and one matching recipient key
Audit and revocation	From the key manager	Nothing in the format; whatever your custody arrangement provides
Hardware compression	Kept	Lost
Certified module	Specific drive models and firmware have held FIPS 140 validations	None

Row by row, with sources and the qualifications each one needs, in the detailed comparison.

The framing is our own work and has not been reviewed outside the project. The primitives are standardized, but the envelope around them is ours, and REM-ENCRYPT is a review draft. What exists is the published specification, pinned test vectors, and a separately written verifier.

Hardware compression is given up. Ciphertext does not compress, and REM-OBJECT has no compression of its own, so material that benefits from compression has to be compressed before archiving. For an archive of compressible material this is the strongest argument for the drive.

There is no certified module and no audit trail in the format. Where a FIPS certificate is a procurement requirement, the drive route exists and this one does not. A key manager also provides logging, revocation, and dual control that a key in a safe does not, although a custody arrangement of your own can supply all three.

An encrypted copy reveals some metadata. Its identifier, size, chunk size, and recipient labels are visible without a key. Member names, sizes, count, and contents are not.

REM-ENCRYPT specifies no key registry and no custody protocol, deliberately. Custody is something the operator brings, in the same way the catalog and the copy policy are, because Remanence is a component, not a product. Putting custody inside it would also defeat the purpose: the part designed to run without keys would become the part that holds them.

What Remanence needs is narrow. It is handed a key at the moment an object is opened, it unwraps the object's key, and it stores nothing. What surrounds that is yours to design, and it is smaller than a key server. An X-Wing private key's stored form is a 32-byte seed, which can go on paper, into metal, or through Shamir's secret sharing so that no one person and no one safe can open the archive alone. An envelope takes up to eight labelled recipients and any one of them opens it, so custody becomes a few named roles: a cold key held split, a warm key for approved restores, and perhaps one held by a second institution.

None of this sits on the archive's availability path. If the custody arrangement is unreachable, the archive can still be verified, repaired, replicated, and migrated, and only the opening of an encrypted copy waits on it.

The roles, the restore procedure, the twice-yearly drill, and the limits on key rotation are set out in key custody. It describes the shape we think that component should have, not software Remanence ships.

Drive encryption is the right choice in several common situations. Where the format is not yours to change, because the archive is written by software you did not write into a container you do not control, the drive is the only control available and an effective one. Where the concern is a cartridge leaving the building, through theft, loss in transit, or disposal of retired media, drive encryption is what the feature was designed for and costs nothing in speed or capacity. Where a validated module, an audit trail, or revocation is required, the drive route has them and this one does not. And where tape is the only medium, application-managed drive encryption with the raw key escrowed by you keeps the compression, the option of a validated module, and a recovery path needing only a drive and a host. What it does not give is keyless upkeep, or one ciphertext across media.

Where an archive has to be verified, repaired, replicated, and migrated for decades, often by people and processes that should not be entitled to read it, we found the boundary belongs earlier, at the object. The gains, in the order they have mattered to us: the key stays in custody, because routine upkeep never needs it; every drive in the library stays in one pool, because no drive is configured for encryption; and if copies are kept on more than one kind of medium, the same ciphertext serves all of them. Whichever is chosen, the key custody plan decides the outcome, and it is the part most often left until last. An archive whose keys are lost is unrecoverable however intact its tapes, and for that reason the encrypted representation is designed around key custody before anything else.

The full argument, with the drive-side mechanics and the sources behind each claim, is in encryption explained. What we encrypt with, and why a post-quantum construction, is on the security page. The envelope is specified in REM-ENCRYPT.