The Asymmetry of Digital Loss & The Tyranny of Tiny Secrets
There is a familiar little cruelty in computing: the thing you need is always easy to lose, while the thing you desperately need to delete seems almost impossible to destroy with certainty.
The document you were working on yesterday has vanished into some folder, profile, cloud sync conflict or application-specific purgatory. The database exists but will not open. The archive is present but corrupt. The email export is technically there, but the one client that understood it has gone to the great software graveyard, beside Lotus Notes and everyone’s patience.
Yet the private key you thought you deleted? The API token that should never have existed in a debug log? The seed phrase briefly copied into a note-taking app? That may still be lounging around in backups, swap files, crash dumps, cloud snapshots, clipboard history, ticket systems, shell history or some forgotten laptop under a desk. Sensitive data, especially small sensitive data, has the survival instincts of a cockroach and the social conscience of a printer driver.
This looks like a contradiction. It is not.
The apparent paradox comes from treating accidental loss and deliberate destruction as equivalent outcomes. They are not. A file can be lost when it is no longer usable; a secret is not destroyed until every useful copy is beyond recovery.
A useful digital artefact is often complex. A document, database, spreadsheet, encrypted volume, CAD drawing, mailbox, VM image or source repository is not just “some bits”. It is structure. It has headers, indexes, metadata, encodings, compression, permissions, application assumptions, paths, version histories and usually a human being who cannot remember whether they called it final, final-final, or final-actually-use-this-one.
Damage any of the wrong parts and the whole object can become effectively inaccessible. Most of the bytes may still exist, but the thing no longer works as the thing. A corrupted archive may contain nearly all its original data and still refuse to extract. A damaged database may contain records but no usable index. A file may be intact but lost because the account, filename, directory structure or encryption context has gone missing.
Usefulness depends on coherence. It depends on the right data being present in the right structure, interpreted by the right software, under the right authority, with the right surrounding context. A large digital object can therefore be lost in practice long before it is physically gone.
Secrets are different.
The secrets we most want to destroy with certainty are often tiny. A symmetric encryption key may be 128 or 256 bits. A token may fit comfortably in a line of text. A password hash, private key, recovery phrase or session cookie is small enough to be copied casually and catastrophically. It can appear in places nobody intended: a log line, a shell history file, a memory dump, a backup, a screenshot, a support ticket, a configuration management repository, a monitoring trace, a developer’s “temporary” script (temporary, here, meaning “until the heat death of the universe”).
This is the central asymmetry: a complex file may need a great deal of its structure to remain useful, but a secret needs only one intact copy to remain dangerous.
For an attacker, one surviving copy is enough. For the defender, proving destruction means accounting for every possible copy. That is not a symmetric task. Recovery requires one success. Destruction requires eliminating the possibility of success across every device, backup, cache, replica, log, export, snapshot and memory image that ever touched the data.
That is why deletion is very different from loss. It is a negative proof problem.
This matters even when we move from logical deletion to physical destruction. Shredding a drive sounds satisfyingly final, and to be fair, it is a great deal better than asking the operating system politely to forget something. But particle size is risk reduction, not magic.
The UK DWP’s 2025 secure sanitisation standard says that, where media cannot be effectively sanitised, physical destruction must be used, the media must be reduced to particles of 6 mm or less, and the achieved particle size must be verified and recorded. (DWP SS-036) That is a serious operational control. It is not, however, a claim that each 6 mm fragment has become blank.
This size recommendation has a heritage tracing all the way back through CESG recommendations and, from my recollection, has not changed in the last 15 years, quite possibly much longer. During that period, storage density has plausibly increased by around three orders of magnitude, while the recommended fragment size has not reduced.
A 6 mm square is small to a human. It is not small to a modern storage medium. Western Digital describes hard drive areal density as the amount of data stored per unit area on a platter, commonly measured in gigabits or terabits per square inch (because why use modern units), and cites densities above 1.3 Tb/in². (Western Digital)
A rough calculation shows why this matters: a 6 mm by 6 mm area is 0.36 square centimetres. At 1.3 Tbit/in², a 6 mm by 6 mm area corresponds to roughly 67–68 Gib, or about 8.4 GiB, before practical recovery limits and overheads. That does not mean a shredded fragment can just be plugged into a USB port. It means that “small fragment” and “no information” are not the same concept. For any serious recovery threat model, that distinction matters.
Someone with enough motivation and capability (including funding) can recover data from fragments like these. For higher-assurance destruction, especially where well-funded laboratory recovery is in scope, shredding may not be the end of the process. Destruction may need to continue into smelting or equivalent treatment under the applicable controlled guidance. And yes, if you are melting the thing, stirring well while molten is a good idea.
The same principle appears in more abstract form with sanitisation standards. NIST frames media sanitisation as rendering access to target data infeasible for a given level of effort, not as an act of metaphysical annihilation. Its current guidance explicitly includes cryptographic erase and secure erase among the relevant techniques. (NIST SP 800-88 Rev. 2) The UK NCSC similarly defines sanitisation as treating data held on storage media to reduce the likelihood of retrieval and reconstruction, and bluntly notes that simply pressing Delete is not enough. (NCSC)
That phrase “for a given level of effort” is doing a lot of work. Security is rarely about absolutes. It is about adversaries, resources, cost, time, confidence and assurance. A process that is perfectly adequate against casual recovery may be inadequate against a nation state, a litigant with money, a hostile insider, or a future version of the same organisation that discovers the allegedly dead system was still backed up to a legacy archive.
Crypto-erasure is the elegant exception, or at least the nearest thing the industry has to one. If bulk data is encrypted properly, and the only key capable of decrypting it is genuinely destroyed, then the remaining ciphertext can be scattered across disks, tapes and cloud object stores without being useful. In that case, the mountain of data is made inaccessible by destroying a tiny secret.
But notice how the same asymmetry returns. Crypto-erasure works only if the key was truly controlled. Was it unique? Was it wrapped by another key? Was it escrowed? Was it backed up? Was it cached in memory? Did it appear in a crash dump? Did an administrator export it during an incident? Did the application ever write plaintext elsewhere? Did the cloud service take snapshots? Did a developer log the decrypted value while debugging something at 2 a.m., when all bad ideas become temporarily plausible?
Destroying the key is powerful because the key is small. Destroying the key is hard for exactly the same reason.
The lesson is not that deletion is hopeless. It is that deletion must be designed, not improvised. Data that may one day need to be destroyed should be created with that end in mind. Secrets should be isolated, rotated, minimised and kept out of logs. Encryption should use clear key hierarchies. Bulk data should be encrypted with data-specific keys where possible, so that crypto-erasure has a defined target. Backups should be part of the deletion model, not treated as a magical attic where compliance goes to sulk. Physical destruction should be matched to the threat model and recorded honestly, without pretending that a certificate changes the laws of information theory.
The apparent paradox dissolves once we separate access from existence.
The document you need can be lost because usability is fragile. It relies on structure, context and interpretation. The secret you need to destroy can survive because danger is compact. It may require only a few intact bytes in one forgotten place.
Computers are not unusually perverse here, although they do seem to have studied the subject. They are simply very good at copying, caching, indexing, compressing, backing up and half-remembering things. Those are useful properties when we want resilience. They are infuriating properties when we want oblivion.
So the rule is simple enough: large useful things are easy to break; small dangerous things are hard to kill.
That is not a contradiction. It is the architecture.
Sophie Baskerville 