{
  "schema": "org-writing@v1",
  "slug": "destroy-the-key",
  "kg": {
    "id": "org:writing:destroy-the-key",
    "type": "brick",
    "graph": "/kg.json"
  },
  "title": "Destroy the key",
  "subtitle": "A ledger can stay whole and a person can still be forgotten, if the personal part is held under a key that can be destroyed",
  "abstract": "How an append-only history and an enforceable right to erasure stop being in conflict, and what the technique costs in honesty. The canonical treatment of cryptographic erasure.",
  "kind": "brick",
  "topics": [
    "Approval",
    "Endings",
    "Provenance at machine scale"
  ],
  "courseMemberships": [
    {
      "course": "org:courses:approval",
      "topic": "Approval",
      "wall": "org:walls:ethics",
      "position": 5,
      "total": 5
    },
    {
      "course": "org:courses:endings",
      "topic": "Endings",
      "wall": "org:walls:ethics",
      "position": 3,
      "total": 4
    },
    {
      "course": "org:courses:provenance",
      "topic": "Provenance at machine scale",
      "wall": "org:walls:engineering",
      "position": 3,
      "total": 5
    }
  ],
  "publishedAt": "2026-08-03T00:00:00.000Z",
  "version": 1,
  "guidelinesVersion": 15,
  "brief": {
    "problem": {
      "text": "A system that must prove what it did keeps an append-only history, and a person described inside that history has a legal right to have their part erased, so the ledger and the right appear to rule each other out.",
      "claims": [
        "a right to erasure under GDPR Article 17"
      ]
    },
    "mechanism": {
      "text": "Erasure operates on the key rather than on the history, so destroying the key leaves the sequence, the hashes, and the replayability intact while the personal content inside becomes unrecoverable.",
      "claims": [
        "destroying the encryption key renders the encrypted data unrecoverable"
      ]
    },
    "move": {
      "text": "Hold personal content under a per-person key stored somewhere else, and state the caveat as loudly as the capability, because the guarantee is exactly as strong as the key management underneath it.",
      "claims": []
    }
  },
  "sources": [
    {
      "repo": "mnstry-research",
      "path": "topics/methodology/assessment/58-forensic-provenance-determinism-replay.md"
    },
    {
      "repo": "mnstry-research",
      "path": "topics/methodology/assessment/63-event-replay-recompute-reframe-architecture.md"
    },
    {
      "repo": "mnstry-research",
      "path": "topics/methodology/assessment/55-submission-contract-versioning-lineage-validation.md"
    }
  ],
  "canonicalPath": "/writing/destroy-the-key/",
  "body": "Two requirements that both look non-negotiable appear to rule each other out. A system that has to prove what it did keeps an append-only history, because a ledger that can be edited is not a ledger; the ordering, the hashes, and the unbroken chain are the whole of its evidentiary value. A person whose life is described inside that history has a right, in European law since 2018 and in ordinary decency for longer, to have their part of it erased. Delete the entry and the chain breaks. Keep the entry and the right is theatre.\n\nThe resolution is to stop treating the record as one substance. Personal content goes into the log encrypted under a key belonging to one person and stored somewhere else entirely, and what the permanent record holds is ciphertext, or a token pointing at a vaulted mapping. The mechanism is that erasure then operates on the key rather than on the history, so destroying the key leaves the sequence, the hashes, and every downstream computation's ability to be replayed exactly intact while the personal content inside them becomes unrecoverable. The security literature calls this crypto-shredding. NIST's media sanitization guidance calls it cryptographic erase and treats it as a legitimate sanitization technique wherever the key management holds up.\n\nWe did not go looking for this pattern. It arrived three times, from three unrelated directions, in research written for three different problems. A study of forensic provenance reached it by asking how an audited decision could still be replayed after a name had been taken out of the log, and answered with a vaulted pseudonym map whose destruction erases the person while leaving the audit whole. An event-replay architecture reached it by asking what deletion can possibly mean in a system where deletion is forbidden and every change has to be a compensating event. A submission-contract study reached it by asking how an append-only multi-tenant log complies with an erasure request at all. Different questions, same answer, and convergence like that is the closest thing engineering has to a second opinion.\n\nThe caveats travel with the technique or the technique is a lie. Cryptographic erasure is exactly as strong as the key management underneath it, and a key that was ever copied to a backup, escrowed with a third party, or wrapped under a second key you still hold has not been destroyed, it has been filed. Its permanence is also a statement about the present state of cryptanalysis rather than a law of nature, which means the honest form of the promise is that the content is unrecoverable now and by any means presently known. Saying that out loud is part of the technique rather than a qualification of it, because a right to be forgotten implemented by people who overstate what they accomplished is not much better than one implemented by people who accomplish nothing.\n\nWhat earns the trouble is the kind of promise it lets you make. Most privacy commitments are behavioral: we will not look, we will not keep it past the date we told you. This one is structural, and its structure is the point, since after the key is gone there is no version of the company, no successor, no acquirer, and no subpoena that can change its mind. A system built to remember everything can still be taught to forget one person completely, and that is what an ending looks like when it is engineered rather than promised.",
  "apparatus": {
    "note": "The human-facing essay is deliberately practical; this apparatus carries the full references, evidence-graded claims, article-local concepts, and research context behind it. Canonical concept definitions come from the concept registry.",
    "references": [
      {
        "id": "org:references:destroy-the-key:r01",
        "author": "National Institute of Standards and Technology",
        "work": "SP 800-88 Revision 1, Guidelines for Media Sanitization",
        "year": 2014,
        "relevance": "The public standard that names the technique: cryptographic erase, in which destroying the key sanitizes the encrypted data, valid where key generation, storage, and destruction are sound."
      },
      {
        "id": "org:references:destroy-the-key:r02",
        "author": "European Union",
        "work": "General Data Protection Regulation, Article 17 (right to erasure)",
        "year": 2018,
        "relevance": "One half of the apparent contradiction the brick resolves: an enforceable individual right to erasure standing against an append-only record that cannot be edited without losing its evidentiary value."
      },
      {
        "id": "org:references:destroy-the-key:r03",
        "author": "MNSTRY research",
        "work": "Three assessment-architecture studies (forensic provenance and determinism, event-replay recompute architecture, submission-contract versioning and lineage)",
        "year": 2026,
        "relevance": "The three independent derivations. Three studies written for unrelated problems arrived at key destruction as the resolution, which is why the pattern is treated here as convergent rather than borrowed."
      }
    ],
    "claims": [
      {
        "id": "org:claims:destroy-the-key:c01",
        "claim": "NIST SP 800-88 Revision 1 recognizes cryptographic erase, in which destroying the encryption key renders the encrypted data unrecoverable, as a media sanitization technique.",
        "basis": "The published standard, which also conditions the technique on sound key generation, storage, and destruction.",
        "confidence": "verified",
        "sources": []
      },
      {
        "id": "org:claims:destroy-the-key:c02",
        "claim": "European law grants a right to erasure under GDPR Article 17, applicable since 2018.",
        "basis": "The regulation's own text and its date of application.",
        "confidence": "verified",
        "sources": []
      },
      {
        "id": "org:claims:destroy-the-key:c03",
        "claim": "Destroying the decryption key leaves an append-only log's ordering and hash chain intact while making the encrypted personal payload unrecoverable.",
        "basis": "Follows from the construction: the chain is computed over ciphertext and metadata, so no chained value depends on the plaintext being readable.",
        "confidence": "verified",
        "sources": []
      },
      {
        "id": "org:claims:destroy-the-key:c04",
        "claim": "Cryptographic erasure holds only under sound key management, and a key that was copied to a backup, escrowed, or wrapped under a second retained key has not been destroyed.",
        "basis": "The standard's own conditions on the technique, and the ordinary operational failure mode.",
        "confidence": "verified",
        "sources": []
      },
      {
        "id": "org:claims:destroy-the-key:c05",
        "claim": "The unrecoverability of ciphertext under a destroyed key is a claim about the present state of cryptanalysis rather than a permanent guarantee.",
        "basis": "The general position of the cryptographic literature on long-horizon guarantees, including harvest-now-decrypt-later risk; not a settled quantity for any particular algorithm or horizon.",
        "confidence": "directional",
        "sources": []
      },
      {
        "id": "org:claims:destroy-the-key:c06",
        "claim": "Three independent MNSTRY research lines, on forensic provenance, event-replay architecture, and submission-contract versioning, each arrived at key destruction as the resolution of the erasure-versus-immutability conflict.",
        "basis": "The three source documents, written for different problems and cited in this piece's sources.",
        "confidence": "verified",
        "sources": []
      }
    ],
    "concepts": [
      {
        "id": "org:concepts:cryptographic-erasure",
        "name": "Cryptographic erasure",
        "definition": "Holding personal content in a permanent record only as ciphertext under a per-person key kept somewhere else, so erasure is performed by destroying the key rather than by editing the record. The ordering, the hashes, and the replayability survive; the personal content does not. Recognized in NIST SP 800-88 Revision 1 as cryptographic erase. Two conditions travel with it and belong in any honest statement of the promise: the guarantee is exactly as strong as the key management underneath, and unrecoverability is a claim about the present state of cryptanalysis rather than a law of nature.",
        "provenance": "canonical"
      }
    ],
    "researchContext": "Harvested from three assessment-architecture research documents, none of\nwhich was written about privacy as its subject; each reached key destruction\nwhile solving something else, and the convergence is the brick's reason for\nexisting. The research is internal, so the public anchors were added at\nauthoring time: the NIST standard for the technique's name and conditions,\nthe GDPR article for the right it satisfies. The surrounding material in all\nthree sources, on replay determinism, bitemporal modeling, and payload\nschemas, is not used. The caveat paragraph is load-bearing rather than\ndecorative: the key-management condition is the standard's own, and the\ncryptanalysis caveat is graded directional because no honest permanence\nclaim about ciphertext is available. What a revocation must reach beyond the\nkey is the delete-is-not-revoke brick's argument, not this one's."
  },
  "contract": "https://mnstry.org/contracts/org/org-writing.v1.schema.json",
  "releaseHash": "289a23308dfaaa7c6f069b1ae40edfe59947d29e7bd839e8c40626fcc05f04b2",
  "versions": [
    {
      "version": 1,
      "cutAt": "2026-08-03",
      "note": "Initial publication, endings wave",
      "visibility": "published",
      "path": "/writing/destroy-the-key/",
      "contentHash": "sha256:2e68fa1f65dcedb3",
      "releaseHash": "289a23308dfaaa7c6f069b1ae40edfe59947d29e7bd839e8c40626fcc05f04b2"
    }
  ]
}