Cryptographic Audit Trail

Three-family post-quantum signatures, canonical serialization, and optional chain anchoring — audit trails that survive vendor change, cloud change, and cryptographic primitive transitions.

A cryptographic audit trail is more than a signed log. It is an audit trail where every property — the entries, the order, the timestamps, the binding between entries and underlying evidence — is cryptographically provable by a third party who does not trust the system that produced it. H33 produces cryptographic audit trails designed for federal and institutional retention windows.

What a cryptographic audit trail must provide

A cryptographic audit trail must satisfy properties beyond standard logging. Entry integrity. Each entry must be verifiable as unmodified since creation. Sequence integrity. The order of entries must be provable. Entries cannot be reordered, deleted from the middle, or inserted retroactively without detection. Time binding. Each entry must be cryptographically bound to a time. Self-reported timestamps are not sufficient. Authority binding. Each entry must be cryptographically bound to the authority that produced it. Policy binding. Each entry must reference the policy in force at the time. Independent verifiability. The audit trail must be verifiable by parties who do not trust the system. Schema stability. The audit trail must remain interpretable across schema evolution. Cryptographic survival. The audit trail must remain verifiable across cryptographic primitive transitions.

How H33 builds cryptographic audit trails

The audit trail is a sequence of evidence bundles. Each bundle covers one event — a decision, a control action, a state change, a notification. Each bundle has the eight standard evidence control objects. The bundle's canonical-JSON commitment is signed by three independent post-quantum algorithm families: ML-DSA-65, FALCON-512, and SLH-DSA-128f. The bundle can optionally include a chain anchor reference. The audit trail is a chain of bundles. Each bundle's PipelineDag object references the prior bundle's commitment via hash chain. The chain is unbroken from the first entry to the most recent. Modifying or removing any bundle breaks the chain at that point.

Why three signature families matter for audit trail retention

A cryptographic audit trail retained for a long window faces the risk that the signature algorithm is broken during the retention window. RSA-2048 signatures applied today and retained for 25 years are bet against the non-existence of a cryptographically-relevant quantum computer through 2050. Single-algorithm post-quantum schemes face the same risk on a different timeline. H33's three-family signature design hedges against single-algorithm failure. ML-DSA-65, FALCON-512, and SLH-DSA-128f rest on independent mathematical assumptions. A break of any one family does not invalidate the audit trail. The trail remains verifiable as long as at least one signature family is intact.

Time binding without trusted clocks

Self-reported timestamps in audit trails are subject to challenge. An entry's timestamp could have been written by the system at any time after the event it claims to document. H33 audit trails support chain anchoring as a time-binding mechanism. The bundle's 32-byte commitment is published as a transaction on a public chain (Avalanche today). The chain's block timestamp provides cryptographic proof that the bundle existed at or before that block. The time binding does not depend on H33's clock, the customer's clock, or any single party's clock.

Use cases

Federal AI usage audit trail. A federal agency's AI inventory generates audit trail bundles for each AI use. The chain establishes the sequence. The signatures establish entry integrity. The chain anchor establishes time binding. Defense system audit trail with decade retention. A defense system's audit trail must remain verifiable through future cryptographic transitions. The three-family signature scheme survives single-algorithm failures. Banking audit trail across vendor transitions. A bank's regulated activities produce audit trail bundles. The bank changes its core banking system. The audit trail remains verifiable under the new system. Healthcare audit trail across HIPAA-mandated retention. A hospital's clinical decision support generates audit trail bundles across vendor changes. Pharmaceutical regulatory audit trail. A pharmaceutical company's trial documentation produces audit trail bundles. The FDA submission includes the bundles. Subsequent inspections decades later verify the same bundles against the same signatures.

Common questions

Is this CNSA 2.0 compliant?
ML-DSA-65 satisfies CNSA 2.0's ML-DSA mandate at NIST level 3. The additional FALCON and SLH-DSA signatures provide diversity beyond the mandate.

What about FIPS 140-3?
The signing keys can be held in FIPS 140-3 validated HSMs.

Does this satisfy NIST 800-53 audit requirements?
H33 cryptographic audit trails produce the audit evidence that 800-53 audit and accountability controls require.

What's the storage footprint?
A typical bundle is tens of kilobytes. Sidecars add proportional to evidence row count. At one bundle per audit event, federal-scale deployments produce manageable storage volumes.

What if the chain anchor blockchain is unavailable?
The base audit trail (bundles, signatures, hash chain) is verifiable without the chain anchor. The anchor provides additional time binding but is not required for audit trail integrity.

Get Started

Run the demo Download the verifier Download a bundle