CDP Specification v1.0¶

The Cryptographic Destruction Proof (CDP) is a signed, hash-chained JSON document that provides verifiable evidence of data destruction. This page defines the canonical format.

Version

CDP version 1.0 — Frozen. The chain structure, hash algorithm, and signature scheme are locked and will not change within the v1.x series.

Format Overview¶

A CDP contains five sections: metadata, the 8-step hash chain, the final hash, the cryptographic attestation, and optional context fields.

{
  "cdp_version": "1.0",
  "session_id": "sess_a8f3e71c4b2d9f06",
  "created_at": "2026-03-01T14:00:00Z",
  "destroyed_at": "2026-03-01T14:30:00Z",
  "chain": [
    {
      "step": 1,
      "subsystem": "eee_namespace",
      "operation": "environment_isolation",
      "evidence_hash": "sha256:7d4f8a...",
      "chain_hash": "sha256:a91b3c..."
    },
    {
      "step": 2,
      "subsystem": "eee_tmpfs",
      "operation": "filesystem_destruction",
      "evidence_hash": "sha256:...",
      "chain_hash": "sha256:..."
    },
    {
      "step": 3,
      "subsystem": "eee_memory",
      "operation": "multipass_overwrite",
      "evidence_hash": "sha256:...",
      "chain_hash": "sha256:..."
    },
    {
      "step": 4,
      "subsystem": "dire_keys",
      "operation": "key_zeroization",
      "evidence_hash": "sha256:...",
      "chain_hash": "sha256:..."
    },
    {
      "step": 5,
      "subsystem": "dire_identity",
      "operation": "credential_incineration",
      "evidence_hash": "sha256:...",
      "chain_hash": "sha256:..."
    },
    {
      "step": 6,
      "subsystem": "fgx_forensic",
      "operation": "merkle_zero_verification",
      "evidence_hash": "sha256:...",
      "chain_hash": "sha256:..."
    },
    {
      "step": 7,
      "subsystem": "rzl_audit",
      "operation": "chain_integrity_seal",
      "evidence_hash": "sha256:...",
      "chain_hash": "sha256:..."
    },
    {
      "step": 8,
      "subsystem": "session_destroy",
      "operation": "lifecycle_completion",
      "evidence_hash": "sha256:...",
      "chain_hash": "sha256:..."
    }
  ],
  "final_hash": "sha256:2c8a4f63d19e7b...",
  "attestation": {
    "algorithm": "Ed25519",
    "public_key": "base64:MCowBQYDK2Vw...",
    "signature": "base64:VGhpcyBpcyBh...",
    "key_id": "nrx-verify-20260301T143000Z-a8f3e71c"
  },
  "session_context": {
    "jurisdiction": "US",
    "data_classification": "PHI"
  },
  "termination": {
    "trigger": "customer_request",
    "command_was_running": false
  },
  "regulatory_context": {
    "notice": "This mapping identifies regulatory provisions potentially related to the destruction evidence. It is not a compliance certification.",
    "framework_version": "2026-02",
    "mappings": [...]
  },
  "component_proofs": {
    "memproof": "sha256:...",
    "zilchnet": "sha256:...",
    "fgx": "sha256:..."
  }
}

Required Fields¶

These fields must be present for a CDP to be valid. Verification will reject CDPs missing any of these.

Field	Type	Description
`cdp_version`	string	Always `"1.0"`
`session_id`	string	Session identifier, prefixed with `sess_`
`created_at`	string	ISO 8601 timestamp — when the session was created
`destroyed_at`	string	ISO 8601 timestamp — when destruction completed
`chain`	array	Exactly 8 chain step objects (see below)
`final_hash`	string	SHA-256 hash matching the last chain step's `chain_hash`
`attestation`	object	Ed25519 signature and public key (see below)

Chain Steps¶

The chain is an ordered array of exactly 8 steps. Each step represents a destruction subsystem that executed during the session teardown.

Chain Step Object¶

Field	Type	Description
`step`	integer	Step number, 1 through 8
`subsystem`	string	Subsystem identifier (see table below)
`operation`	string	Operation performed by this subsystem
`evidence_hash`	string	SHA-256 hash of the subsystem's execution evidence
`chain_hash`	string	SHA-256 hash linking this step to the previous one

Step Definitions¶

Step	Subsystem	Operation	What It Proves
1	`eee_namespace`	`environment_isolation`	Linux namespace was created and isolated
2	`eee_tmpfs`	`filesystem_destruction`	Volatile filesystem was unmounted and destroyed
3	`eee_memory`	`multipass_overwrite`	Memory was overwritten using DoD 5220.22-M multi-pass wipe
4	`dire_keys`	`key_zeroization`	Cryptographic keys were zeroized from memory
5	`dire_identity`	`credential_incineration`	Session credentials were destroyed
6	`fgx_forensic`	`merkle_zero_verification`	Forensic Merkle tree confirms zero residual data
7	`rzl_audit`	`chain_integrity_seal`	Hash chain integrity validated before sealing
8	`session_destroy`	`lifecycle_completion`	Session lifecycle terminated, all resources freed

Hash Chain Algorithm¶

The chain uses SHA-256 with the following computation:

Genesis hash: SHA-256("") = e3b0c44298fc1c149afbf4c8996fb924...

Step N chain_hash: SHA-256(
    prev_chain_hash  \x00
    subsystem        \x00
    "destroy"        \x00
    method           \x00
    timestamp
)

Where prev_chain_hash is the genesis hash for step 1, or the previous step's chain_hash for steps 2-8. The \x00 byte is used as a field separator.

The final_hash must equal the chain_hash of step 8.

Attestation¶

The attestation provides a cryptographic signature over the destruction evidence.

Field	Type	Description
`algorithm`	string	Always `"Ed25519"`
`public_key`	string	Base64-encoded Ed25519 public key, prefixed with `base64:`
`signature`	string	Base64-encoded Ed25519 signature, prefixed with `base64:`
`key_id`	string	Key identifier in format `nrx-verify-{timestamp}-{cdp_id_prefix}`

Signature Computation¶

The signature is computed over the hex-encoded bytes of step 8's chain_hash (with the sha256: prefix stripped):

message = hex_decode(step_8.chain_hash without "sha256:" prefix)
signature = Ed25519_Sign(private_key, message)

Ephemeral Keys¶

Each session generates a unique Ed25519 keypair. The private key is used exactly once (to sign the CDP) and is then zeroized from memory. The public key is embedded in the CDP and also stored in Nanorix's key database for optional provenance verification.

Optional Fields¶

These fields provide additional context but are not required for cryptographic verification.

session_context¶

Customer-declared metadata about the session. Nanorix does not verify these declarations.

Field	Type	Description
`jurisdiction`	string	Customer-declared jurisdiction: `"US"`, `"EU"`, `"UK"`, `"CA"`, `"AU"`, `"IN"`, `"OTHER"`
`data_classification`	string	Customer-declared data type: `"PHI"`, `"PII"`, `"financial"`, `"credentials"`, `"general"`

termination¶

Metadata about how the session ended.

Field	Type	Description
`trigger`	string	`"customer_request"`, `"ttl_expired"`, or `"system_restart"`
`command_was_running`	boolean	Whether a command was executing when destruction began
`command_completed`	boolean	Whether the running command finished before destruction (only present if `command_was_running` is true)

regulatory_context¶

A factual mapping of destruction steps to regulatory provisions. See Regulatory Context for full documentation.

Not a compliance certification

The regulatory_context field identifies regulatory provisions potentially related to the destruction evidence. It is not a compliance certification. Compliance determinations should be made by qualified legal and compliance professionals.

component_proofs¶

Individual proof hashes from subsystems that performed real, verifiable operations. Only populated for subsystems with live implementations.

Field	Type	Description
`memproof`	string	SHA-256 hash from multi-pass memory overwrite verification
`zilchnet`	string	SHA-256 hash from network namespace isolation verification
`fgx`	string	SHA-256 hash from forensic Merkle tree verification

Partial CDPs¶

If a session cannot complete the full 8-step destruction (e.g., server restart, lost state), a partial CDP is generated.

Partial CDPs include:

{
  "cdp_version": "1.0",
  "completeness": "partial",
  "reason": "session_state_lost_on_restart",
  "chain": [...],
  "...": "..."
}

The completeness field distinguishes partial from complete CDPs. Partial CDPs may have fewer than 8 chain steps and may not include a valid signature.

Verification¶

CDPs can be verified using three methods:

Offline — Recompute the hash chain from genesis, verify final_hash matches step 8, verify the Ed25519 signature using the embedded public_key. Zero network calls needed.
API — POST /v1/verify with the CDP JSON body. Returns verification result.
Web — Drag-and-drop at nanorix.io/verify. Runs entirely client-side.

For detailed verification instructions, see Verification.

Versioning¶

The cdp_version field uses semantic versioning within the 1.x series:

1.0 — Current. 8-step chain, SHA-256, Ed25519.
Future minor versions (1.1, 1.2) may add optional fields but will not change the chain structure or cryptographic algorithms.
A version 2.0 would indicate breaking changes to the chain format.

The chain structure (8 steps, hash algorithm, signature scheme) is frozen for all v1.x releases.