Security for an archive that has to last decades.

Archives face a fairly specific set of attacks, and each one shaped a different part of the design.

The first is backup destruction ahead of a ransom demand. Modern ransomware operations find and destroy backups and their catalogs before encrypting the production systems, so that the victim has nothing to restore from. The catalog is the soft target: destroy the map and the data is unreachable even though the tapes survive.

The second is tampered media. A cartridge has to be treated as untrusted input. Anyone who ever had write access to it, or who hands you one, controls the bytes your restore software is about to parse. Malformed archive structures are a well-known route into the machine doing the reading, and altered content is a route to corrupting what you believe you preserved.

The third is theft now for decryption later. An off-site copy can be stolen today and held until the cryptography protecting it weakens. Archives are a natural target for this, because their contents must stay confidential for decades rather than months.

The fourth is compromise of the host. The machine that drives the tape library is a computer like any other. An attacker who controls it controls every mounted tape.

Finding exploitable bugs and building attack tooling has become cheaper, and current AI models are making it cheaper still, so it no longer needs a well-resourced team. We would not stake a decades-long archive on a more optimistic reading, and we would rather describe our position in public, in detail, before being asked.

Remanence was written from first principles, in Rust, on the raw SCSI interface. Starting from the ground up made it possible to remove whole classes of weakness rather than patch around them.

The restore path treats every byte it reads as untrusted. REM-OBJECT is a deliberately constrained archive grammar, one fixed layout rather than the many dialects a general tar reader has to accept, and it is parsed in a memory-safe language. The bug classes that have historically turned archive parsers into footholds, buffer overflows and use-after-free, are excluded by the language rather than by programmer discipline.

File metadata on a cartridge cannot change the configuration of the machine that reads it. Some file metadata carries privilege: Linux capabilities, access control lists, SELinux labels. Remanence stores such attributes but never reapplies them by default. A restore covers the harmless user namespace only, anything privileged needs an explicit per-restore opt-in, and the restore report lists what was skipped and what was applied. Ownership and setuid bits are not preserved at all. Attributes live in the object's manifest rather than in tar headers, so even a recovery with a forty-year-old tar cannot escalate privilege through file metadata. The extended-attributes reference has the full rules.

Tampering is detectable, within limits we state. Every file carries a SHA-256 digest, every object carries a manifest digest and a whole-object digest, the parity structures carry checksums, and each tape derives its own signature values from its identity, so blocks from one tape cannot pass as another's. All of this catches corruption and accidental alteration. What it cannot do, on a plaintext tape alone, is defeat an attacker who can rewrite the whole cartridge, because they can recompute every digest and leave a self-consistent forgery. The specification says this itself, in a section titled No Authentication. Authenticity needs anchors the tape cannot rewrite: the digests held off-tape in the catalog and journals, and the encrypted representation, whose manifest travels inside an authenticated, encrypted frame.

Off-site copies use post-quantum encryption. REM-ENCRYPT uses a hybrid of conventional and post-quantum cryptography, X-Wing, which combines X25519 with the FIPS-standardized ML-KEM-768, with a fresh key for every object. Remanence pins X-Wing at revision 10 of its March 2026 draft; the same construction is now carried forward by the IETF's Crypto Forum Research Group as MLKEM768-X25519 and is on a standards-track path through HPKE. A stolen cartridge is protected by two independent key-establishment schemes, and an attacker would have to break both. The post-quantum scheme is newer and less studied than the conventional one, which is exactly why the design uses the hybrid rather than either alone.

All privileged hardware access runs through one daemon, behind mutually authenticated TLS. Before writing, a tape's identity is proven twice, first by the library's barcode against the catalog and then by the identity block on the tape itself, and every operation lands in an append-only audit trail. There are no root shell scripts interpolating device names, which are a common source of privilege and injection bugs in traditional tape tooling. Two case studies on that choice are in the documentation.

Destroying the catalog does not destroy the archive. The host-side index is a cache. Each tape carries its own identity, its read parameters, and an inventory of its contents, so the data can be recovered from the cartridges alone. Destroying the servers becomes a recoverable event, and a ransom demand loses much of its leverage.

The final defence is physical. The design assumes several copies on independent storage families, with cartridges out of any robot's reach. No network compromise reaches a tape on a shelf, and the formats are built so that a shelf of tapes is enough to start again. A small set of core routines, the ones where a mistake would silently corrupt data, is additionally verified by machine-checked proof in Lean.

This is young software. The traditional tools have had decades of adversarial attention, and their remaining bugs are the deep ones. This implementation is at the start of that process, and undiscovered bugs certainly exist, including logic errors that no programming language prevents. Memory safety, a constrained format, and proofs reduce where a bug can be, without removing the possibility.

Concentrating privileged access in one daemon reduces the attack surface but creates a high-value target: compromising that daemon means raw SCSI control of the library. And no software protects an archive whose operating environment is fully compromised. That weight is carried by procedure, meaning offline copies, separated key custody, and restore drills. Open security work is tracked on the public issue tracker, not resolved in private.

Trust in security claims should come from failed attempts to break them, and a young system needs those attempts more than an old one does. Everything needed to attack this design honestly is published: the specifications, the reference implementation, pinned test vectors, and an evaluation path that runs against a virtual tape library before any hardware is involved.

If you can corrupt an object without detection, make a restore emit wrong bytes, defeat the parity layer, confuse the identity checks, or get past the daemon, we want to know. Reports are welcome by email or through GitHub's private vulnerability reporting. Findings that are safe to discuss openly can go straight to the issue tracker.

Set up an evaluation environment → ·  Report by email → ·  Report privately on GitHub → ·  View the source →