Hardware tape encryption compared with encryption in the object.

Encryption entered the LTO format at generation 4. The drive holds an AES-256-GCM engine on the data path: data is compressed first, encrypted second, and written third, all at line rate, so an encrypted write is no slower than an unencrypted one. The key reaches the drive over the ordinary SCSI interface and is held only while the drive is powered and the cartridge is loaded. It is never written to the cartridge, and it is discarded at unload. Alongside the data the drive records a short field called Key Associated Data, whose purpose is to name which key was used.

Key management is deliberately left outside the format. The LTO Program is explicit that "key management is not part of the LTO Ultrium drive specification", and points instead at third-party products speaking the OASIS KMIP protocol. Three arrangements are in common use:

• Application-managed. The writing application holds the keys and supplies one to the drive at each mount.
• Library-managed. The tape library obtains keys from a key manager, usually over KMIP, and applies them according to policy — commonly per library partition or per range of cartridge barcodes. Encryption is transparent to the application, which is the main attraction.
• System-managed. A driver or operating-system layer performs the same role.

Library-managed encryption with a KMIP key manager is what most sites deploy, and it is the arrangement the rest of this page has in mind when it refers to drive encryption.

None of the above is criticism. It is a well-engineered feature that solves the problem it was designed for — a cartridge that leaves the building should be unreadable — and it solves it at no cost in throughput. Our disagreement is about a different problem.

Property	Drive encryption	REM-ENCRYPT
Cipher	AES-256-GCM in drive silicon	ChaCha20-Poly1305 with HKDF-SHA-256; key wrapped with HPKE and X-Wing
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 ever copied to
Key granularity	Per write session; in practice per cartridge	Per object
Recipients	One key	One to eight recipient public keys per object
Verify a copy without the key	No	Yes
Repair from parity without the key	No	Yes
Migrate to new media	Decrypt, cross the host in the clear, re-encrypt	Copy the bytes; no key is loaded
What the medium says about the encryption	A key identifier	Format version, cipher suite, wrapping mechanism, salt, recipients, and the wrapped key
Needed to read it in fifty years	A compatible drive, a key manager that can still present a key to it, and the key	The published specification, any implementation of it, and the key
Hardware compression	Retained — the drive compresses before it encrypts	Forfeited
Cost in CPU	None	One pass over the data
Certified cryptographic module	Yes — several LTO generations hold FIPS 140 validations	No; published specification, test vectors, and external review instead

Sources for the drive column: the LTO Program's encryption page, the IBM LTO SCSI Reference, and the NIST CMVP security policies for the HPE and IBM LTO-7/8 drives. The open-source stenc utility is a readable demonstration of the commands involved.

A durable archive keeps more than one copy, and careful practice puts them on more than one kind of medium, since a fault that reaches one technology tends not to reach a different one. In most archives that means tape plus disk, and often a further copy held somewhere else entirely.

Drive encryption protects the copies that are on tape. It does nothing for the others. Their confidentiality has to be arranged separately, by a different mechanism, with its own key custody, its own rotation schedule, and its own list of who may hold a key. The archive then runs two encryption systems that agree about nothing, and the weaker of the two sets the real standard.

There is a second consequence that appears during repair. If the disk copy is lost and has to be rebuilt from tape, the data is decrypted by the drive, crosses the host in the clear, and is re-encrypted by whatever protects the disk. Every repair passes through plaintext, and repairs are routine.

Encrypting in the object removes the question rather than answering it. There is one ciphertext, and every copy is a copy of it, byte for byte, wherever it is kept.

Writing an object happens once. Everything else happens again and again for as long as the collection is held: reading copies back to confirm they are still intact, scrubbing cartridges on a schedule to find blocks that have begun to fail, rebuilding a damaged region from parity, making an additional copy, and eventually moving the whole archive to newer media.

With encryption in the drive, all of that runs through the decryption path. A tape can only be verified in a drive that has been given the key, which means the key manager has to be reachable and the key has to be released — for an operation whose only purpose is to confirm that bytes are still the bytes that were written. The authority to read the archive has to be continuously available in order to check on it.

With encryption in the object, the ciphertext is what gets stored, checksummed, replicated and repaired. Its digest is a property of the stored bytes, so a copy can be shown to be undamaged without opening it. REM-ENCRYPT states this as a design goal: storage, replication, parity repair and scrubbing of stored bytes all proceed with no key present.

That has a practical consequence which we did not anticipate before operating it. The person or system that verifies the archive need not be entitled to read it. A cartridge can be sent to another site for checking, or held by another institution as a third copy, and the holder can prove it is undamaged and even repair it from parity without being able to see what it contains. Custody and access become separate permissions, which is a distinction most preservation policies want and few storage systems allow.

Tape archives move. Since LTO-8 a drive reads only its own generation and the one before it, and LTO-10 reads only its own generation. Whatever the media is rated for, the practical horizon of a cartridge is set by how long a drive exists that can read it, and every archive on tape is therefore copied forward every several years whether it planned to be or not. Over a few decades this is the largest recurring operation an archive performs, and the one most likely to be performed under time pressure.

Under drive encryption the usual path is that the old drive decrypts, the data crosses the host in the clear, and the new drive encrypts again under a new key. It works. But plaintext exists on every cycle, the operator running the migration needs the authority to read everything being moved, and each cycle adds another key that has to be kept for as long as any cartridge written under it survives.

Under encryption in the object, migration copies bytes. No key is loaded, no plaintext is produced, and the migration can be run by someone with no entitlement to the contents. Since this is the operation the archive will perform most often, and under the least favourable conditions, it seemed the right one to design around.

In fairness to the drive: the SCSI command set does provide a raw mode in which a drive returns encrypted blocks without decrypting them, which allows a cartridge to be duplicated without the key. Vendor documentation treats this as a weakness to be aware of rather than a feature to rely on, and it clones like for like rather than migrating between generations. It is not a general answer, but it is only honest to say the capability exists.

The Key Associated Data field names a key. It does not say which algorithm was used, in which mode, how the key was derived or wrapped, or whether anyone else holds one. All of that lives in the key manager's database and in the conventions of the product that wrote the tape. A key recovered from a safe thirty years later, without that database, is a number with nothing to attach it to.

This is the same failure the rest of the format was built to avoid, appearing in the one place it is easiest to overlook. An archive will take care to keep its file manifests and checksums with the data, and then leave the description of its own encryption in an appliance that will be decommissioned in five years.

REM-ENCRYPT puts the envelope in the object: format version, cipher suite, key wrapping mechanism, salt, the recipient identifiers, the wrapped key itself, and the geometry needed to locate anything inside. Recovery is defined from the first stored block using nothing but the object and one matching private key — no catalog, no database, no service to call.

KMIP is carried over TLS, normally with certificates authenticating both the library and the key server. Key managers are commercial products or appliances with support lifetimes, licence terms, version migrations and end-of-life dates, and vendors reasonably recommend running at least two of them for redundancy. None of this is a criticism; it describes ordinary enterprise software, competently built. It is simply not the same kind of object as a thirty-year archive.

The failure that follows is quiet and easy to picture. The tapes are in good condition, a working drive is available, and the key is safely on file — and nothing in the building can present that key to that drive in the manner it expects, because the key manager it was paired with was retired two versions ago and the certificate authority that authenticated it expired before that. Nothing was lost through carelessness. The dependency simply outlived the thing it depended on.

With the envelope inside the object, key custody can be arranged to suit the archive rather than the product. A recipient private key can be held in a hardware token, printed and sealed, or divided among several holders, and recovery needs the key and a reader rather than a running service on a reachable network. REM-ENCRYPT defines no key registry and no custody protocol on purpose: that decision belongs to the institution, and it is the decision that most deserves care. An archive that outlives its keys is lost as thoroughly as if the tapes had burned.

One difference is operational rather than architectural, and it shows up quickly in a library that holds both encrypted and unencrypted collections. Where encryption is applied by library policy, the policy attaches to a partition or a range of cartridge barcodes, and the drives serving it encrypt everything they write. The drive estate divides into encrypting and non-encrypting drives, and a drive failure is then not only a drive failure — it is the loss of the ability to write one of the two kinds of copy until the drive is replaced.

To be accurate, this is a property of how key management is deployed rather than of the hardware. At the command level, encryption parameters are set per mount and cleared when the cartridge unloads, nothing pins a drive permanently to one mode, and a cartridge may even carry both encrypted and unencrypted records, though whole-cartridge encryption is the norm. The rigidity comes from library-managed policy, which is the arrangement most sites run.

There is a circularity worth noticing in the alternative. The flexible arrangement — application-managed encryption, with the key supplied at each mount — requires the application to hold the keys, bind them to cartridges, and deliver them itself. That is the same key-custody work that encrypting in the object requires, undertaken without gaining the portability across media or the self-description that come with it.

With encryption in the object, every drive is the same drive, and any drive writes any copy.

Hardware compression is given up. The drive compresses before it encrypts, so drive-encrypted data still benefits from LTO's compression. Object-encrypted data arrives at the drive as ciphertext, which does not compress at all, and REM-OBJECT contains no compression of its own — the payloads it was designed for are already-compressed video and images, where LTO's compression achieves close to nothing, and compressing the stream as a whole would destroy the byte-range addressing that makes partial restore possible. For an archive of genuinely compressible material — uncompressed image sequences, text corpora, database exports — this is a real cost that cannot be recovered later, and it is the strongest argument for the drive.

Encryption costs processor time. It is a full pass over every byte, in addition to the pass already spent computing checksums. A current processor encrypts several times faster than a tape drive writes, so it is not the limiting factor in practice, but it is a cost the drive does not have and it is one more thing competing for the machine that is feeding the drive.

There is no certified module. Several LTO generations hold FIPS 140 validations, and where a certificate is a procurement requirement rather than an engineering one, the drive satisfies it and we do not. REM-ENCRYPT offers a different kind of assurance — a published specification, fixed test vectors, an independent implementation, and external review — and some organizations are not permitted to substitute one for the other. The cipher suite is a registered field, so a validated alternative could be assigned, but none is today.

The framing is our own work. The cipher and the key-wrapping construction are standard and well studied; the envelope around them is ours. A defect there would be ours, and it would appear in the worst possible place — years later, in a copy nobody had opened.

An encrypted copy is not entirely silent. It reveals that it is a REM-ENCRYPT object, its identifier, its approximate size, and the recipient identifiers it was sealed to. Member names, sizes, count and contents are hidden. Where the existence or the size of an object is itself sensitive, that needs policy above the format. The format also proves confidentiality and self-consistency rather than authorship: an object proves what it is, not who wrote it, and an archive needing provenance should sign an external manifest as well.

Drive encryption is the right choice more often than this page might suggest.

• Where the format is not yours to change. Most archives are written by software they did not write, into a container they do not control. Encryption in the object is not an option that is available to them, and the drive is the only lever there is. It is a good lever.
• Where the concern is a cartridge leaving the building. Theft, loss in transit, or the disposal of retired media. That is the problem the feature was designed for and it addresses it squarely, at no cost in speed or capacity.
• Where a validated hardware module is required by regulation or by contract.
• Where the material compresses well and the capacity matters more than the rest of what is discussed here.
• Where tape is the only medium and the archive is not expected to outlive its key management.

Applying both together buys less than it appears to. Once the data is ciphertext the drive's compression is already lost, so the second layer protects material that is already protected, while restoring the key-manager dependency on the read path that encryption in the object was chosen to avoid. Where a certificate demands it the two compose without difficulty. Otherwise there is little reason.

The choice follows from what the archive has to survive, which is the same test that decides the format question.

• Where the risk is physical and the archive lives on one kind of medium, the drive is doing the job it was designed for, and doing it without costing anything.
• Where the archive spans several media and 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.
• Whichever is chosen, the key custody plan decides the outcome. It is the part most often left until last, and it is the only part with no technical remedy. A cipher can be replaced and a format can be migrated; a key that no one holds cannot be recovered by any means.

Encryption in the REM formats is optional and deliberately separate from the durable object. An archive that does not need confidentiality writes plain REM-OBJECT and loses none of the fixity, parity or catalog-free recovery. An archive that needs it for certain copies applies it to those copies. The point of keeping the two apart is that cryptography is revised on a schedule of its own, and the preserved format should not have to be revised with it.

The reasoning above is about where the boundary sits. What we encrypt with, and why a post-quantum construction was chosen for material that must stay confidential for decades, is covered on the security page; the envelope itself is specified in REM-ENCRYPT.