Attackers improve. Archived data does not.

Offensive capability keeps getting cheaper, and AI is pushing that along quickly. Work that until recently needed a skilled, well-resourced team — finding exploitable bugs, writing attack tooling, running patient intrusion campaigns — is now within reach of ordinary actors using rented models, and the reach grows with every model generation. We would not stake a decades-long archive on a more optimistic reading.

That shifts one question to the front for any software this important: how it behaves when someone competent is deliberately trying to break it. We would rather answer that question in public, in detail, and before being asked.

Archives face a fairly specific set of attacks, and it helps to name them precisely, because each one shaped a different part of the design.

Backup destruction before ransom. Modern ransomware operations locate and destroy backups and their catalogs first, so the victim has nothing to restore from. The catalog and index are the soft target here — kill the map and the data becomes unreachable even when the tapes survive.

Tampered media. A cartridge is 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 classic route into the reading machine, and altered content is a route to corrupting what you think you preserved.

Harvest now, decrypt later. Off-site copies can be stolen today and held until the cryptography protecting them weakens. Archives are the prime target for this, precisely because their contents must stay confidential for decades rather than months.

Compromise of the operating host. The machine that drives the tape library is a computer like any other. If an attacker controls it, they control every mounted tape.

Remanence was built from first principles, in Rust, on the raw SCSI interface. Starting from the ground up mattered because it let us remove whole classes of weakness rather than patch around them.

The restore path assumes hostile bytes. REM-OBJECT is a deliberately constrained archive grammar — one deterministic layout, not the full dialect zoo a general tar reader must accept — parsed in a memory-safe language. The bug classes that historically turn an archive parser into a foothold, buffer overflows and use-after-free, are mostly excluded by the language itself rather than by programmer discipline.

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

Tampering is detectable by design. Every file carries a SHA-256 digest, every object carries a manifest digest and a whole-object digest, and the parity layer's structures carry checksums. Each tape derives its own magic numbers from its identity, so blocks from one tape cannot masquerade as another's. To alter archived bytes without being caught you have to break SHA-256, not merely be careful.

Off-site copies use post-quantum encryption. REM-ENCRYPT uses a hybrid of conventional and post-quantum cryptography (X-Wing: X25519 with ML-KEM-768), with a fresh key for every object. A stolen cartridge is protected by two independent key-establishment schemes, and an attacker would need to break both. The post-quantum scheme is newer and less studied than the conventional one, and that is exactly why the design uses the hybrid rather than either alone.

One funnel, watched. All privileged hardware access runs through a single daemon behind mutually authenticated TLS. Before writing, tape identity is proven twice — the library's barcode against the catalog, then 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 is a common source of privilege and injection bugs in traditional tape tooling. Two case studies on that choice are in the documentation.

The catalog cannot be held hostage. The host-side index is a cache, never the truth. Each tape carries its own identity, its read parameters, and a growing inventory of its contents, so the archive can be rebuilt from the cartridges alone. Destroying the servers becomes a recoverable event, and that takes much of the leverage out of a ransom demand.

The last line is offline. The design assumes multiple copies on independent storage families, with cartridges out of any robot's reach. No network compromise reaches a tape sitting 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 mathematical proof in Lean.

A security page that lists only strengths is a marketing page, so here is what we cannot claim.

This is young software. The traditional tools have had decades of adversarial attention, and their remaining bugs are deep ones. This implementation is at the start of that process, and undiscovered bugs certainly exist — including, in principle, logic errors that no programming language prevents. Memory safety, constrained formats, and proofs shrink the places a bug can hide. They do not shrink them to zero.

Concentrating privileged access in one daemon cuts the attack surface, but it also 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: offline copies, separated key custody, restore drills. Open security work is tracked publicly on the 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 required 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's funnel, we want to know about it. 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 →