Post-Quantum Cryptography Transition Guide

Making the AI Governance Evidence Infrastructure Quantum-Ready
License: Apache License 2.0

1. Executive Summary

The core value proposition of the AI Governance Evidence Infrastructure (AGEI) and the Cognitive Insight Audit Framework (CIAF) is "Proof, Not Logs." To achieve this, the architecture relies heavily on cryptographic primitives to guarantee the integrity, non-repudiation, and lineage tracking of lifecycle receipts, gate evaluations, and Evidence Vault custody objects.

However, the rapid development of quantum computing introduces a critical vulnerability to classical public-key cryptography. This guide establishes the technical specification to transition the framework to a Post-Quantum Cryptography (PQC) posture, aligning with the official NIST FIPS standards published in August 2024 (FIPS 203, 204, and 205).

Rather than proposing a complete rip-and-replace, this specification advocates for a Hybrid Cryptographic Design—allowing organizations to layer quantum-safe algorithms over existing classical implementations (such as Ed25519 and SHA-256) to maintain immediate real-world interoperability while protecting evidence against future decryption and forgery threats.

2. The Quantum Threat Model for AGEI & CIAF

Quantum computers do not simply speed up classical search; they exploit quantum mechanical phenomena (superposition and interference) to solve specific mathematical problems in polynomial time. The threat to our evidence infrastructure falls into two categories:

2.1 The Signature Collapse (Shor's Algorithm)

Shor's algorithm solves the discrete logarithm problem over elliptic curves (and prime factorization for RSA) in polynomial time.

  • Current Vulnerability: Our standard signature algorithm, Ed25519 (EdDSA over Curve25519), is completely broken under Shor's algorithm.
  • The Governance Impact: If an adversary gains access to a cryptographically relevant quantum computer (CRQC), they can calculate the private key from any published public key. This allows them to:
    1. Forge historical receipts: Fabricate validation, deployment, or approval receipts that appear fully authentic.
    2. Rewrite agent lineage: Alter parent-child agent delegations and JIT elevations to obscure unauthorized tool actions.
    3. Spoof human oversight: Sign-off on high-risk gate bypasses or overrides under a trusted investigator's identity.

2.2 The Hashing Reduction (Grover's Algorithm)

Grover's algorithm speeds up unstructured database searches, reducing the security strength of symmetric keys and hash functions to their square root.

  • Current Vulnerability: For SHA-256, Grover's algorithm reduces the collision resistance from 256 bits to 128 bits of pre-image resistance.
  • The Governance Impact: While a 128-bit security margin remains safe against brute-force attacks, high-security profiles (such as Forensic Evidence, Profile 3) must prepare for long-term vault custody where content hashes must remain unchallenged for decades.

3. Algorithm Selection for PQC Transition

To secure the framework, we adopt the primary signature algorithms standardized by the NIST Post-Quantum Cryptography Standardization Project:

3.1 ML-DSA (Module-Lattice-Based Digital Signature Algorithm - FIPS 204)

  • Underlying Hardness: Module Learning with Errors (M-LWE).
  • Application in AGEI: The default standard replacement for Ed25519 for all receipt signing, gate evaluations, and audit packs.
  • Selected Parameters:
    • ML-DSA-65 (Category 3 / equivalent to AES-192): The primary standard for standard-level enterprise receipts.
    • ML-DSA-87 (Category 5 / equivalent to AES-256): Reserved for high-assurance forensic receipts, root KMS authorities, and Evidence Vault custody seals.

3.2 Falcon / FN-DSA (FFT-Over-NTRU Digital Signature Algorithm - FIPS 206)

  • Underlying Hardness: Short Integer Solution (SIS) over NTRU lattices.
  • Application in AGEI: Optimal for lightweight runtime receipts (such as continuous agent tool proposals) because Falcon signatures are significantly smaller than ML-DSA signatures, reducing the network payload overhead during active execution loops.
  • Parameter: Falcon-512 (Category 1 / equivalent to AES-128).

3.3 SLH-DSA (State-Less Hash-Based Digital Signature Algorithm - FIPS 205)

  • Underlying Hardness: Security properties of the underlying cryptographic hash function (SHA-2 or SHAKE).
  • Application in AGEI: Used as a fail-safe fallback for root keys and high-assurance Evidence Vault seals. Because it does not rely on lattice mathematics, it remains secure even if future mathematical breakthroughs compromise lattice-based schemes.
  • Parameter: SLH-DSA-SHA2-128f or SLH-DSA-SHA2-256f.

4. Hybrid Cryptographic Envelopes (The Dual-Signature Model)

Because PQC algorithms are relatively new and lack the decades of optimization and hardware-acceleration available to elliptic curves, a hybrid signature mechanism is the most secure migration pathway.

All receipts and gate evaluations in a hybrid configuration carry a dual-signature envelope. A verifier checks both signatures; the verification fails if either signature is invalid.

4.1 Hybrid Receipt Payload Structure

An AGEI receipt payload is first canonicalized using the ciaf-json-v1 protocol and hashed using SHA-256. The resulting digest is then wrapped in a hybrid envelope:

{
  "receipt_id": "rcpt:deploy:2026-08-12:0048",
  "receipt_type": "deployment_approval",
  "canonicalization_version": "ciaf-json-v1",
  "hash_algorithm": "SHA-256",
  "content_hash": "e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855",
  "signature_metadata": {
    "envelope_type": "hybrid-ecdsa-mldsa",
    "classical_signature": {
      "algorithm": "Ed25519",
      "key_id": "kms:prod:ed25519:2026",
      "signature": "8a329d91f8...[64 bytes hex]"
    },
    "post_quantum_signature": {
      "algorithm": "ML-DSA-65",
      "key_id": "kms:prod:mldsa65:2026",
      "signature": "b4198d02c8...[3300 bytes hex]"
    }
  }
}

5. Architectural Schema Impact & Key Management

Upgrading your database schema to handle PQC algorithms introduces distinct storage and performance considerations because post-quantum public keys and signatures are substantially larger than classical elliptic curves:

AlgorithmPublic Key Size (Bytes)Signature Size (Bytes)Performance (Sign / s)Performance (Verify / s)
Ed25519 (Classical)3264~20,000~10,000
ML-DSA-65 (PQC Default)1,9523,300~11,000~22,000
Falcon-512 (PQC Compact)897666~1,000~20,000
SLH-DSA-128f (PQC Stateless)3217,088~250~1,200

5.1 Relational Schema Adjustments

To accommodate these changes in your 60-table relational schema contract, you must implement the following structural changes:

  1. Enlarge Signature Columns: In the receipts and vault_objects tables, the signature column must be defined as TEXT or BYTEA rather than fixed-length character fields (VARCHAR(128)), to seamlessly support SPHINCS+ signatures exceeding 17KB.
  2. Upgrade Hashing Options: Add SHA-512 and SHA3-256 to the allowed vocabularies of hash_algorithm columns to offset Grover's algorithm pre-image security degradation.
  3. Expanded Key Registry: The cryptographic key identifier (key_id) must route to a key store capable of binding hybrid identities.

6. Verification & Migration Workflow

A post-quantum verification job (verification_jobs) executes the following state machine when validating a candidate audit pack or receipt chain:

6.1 State Machine Verification Steps:

  1. Ingestion: Retrieve the suspect receipt and extract the signature_metadata block.
  2. Normalization: Strip the signature blocks and canonicalize the remaining receipt body using JSON Canonicalization Scheme (RFC 8785 / JCS).
  3. Hash Verification: Re-hash the canonical bytes using SHA-256. Confirm that it matches the receipt's declared content_hash.
  4. Classical Signature Validation: Retrieve the classical public key via kms:prod:ed25519:2026. Verify the classical_signature over the recomputed hash.
  5. Post-Quantum Signature Validation: Retrieve the lattice public key via kms:prod:mldsa65:2026. Verify the post_quantum_signature over the recomputed hash.
  6. Linage Chain-of-Custody Check: Traverse the receipt_links and confirm that all ancestor and predecessor hashes remain cryptographically bound.

7. Code Example: Python Hybrid Verification Mockup

Below is a reference implementation showing how a Python verification service can canonicalize an object, verify its hashes, and assert dual-signature verification of a hybrid receipt.

import json
import hashlib
from typing import Dict, Any

# We use JCS canonicalization to ensure cross-language hash consistency
import jcs  # Python implementation of RFC 8785 (JSON Canonicalization Scheme)

# Mocked cryptographic validation libraries for demonstration
class MockCryptoEngine:
    @staticmethod
    def verify_ed25519(public_key_id: str, message: bytes, signature_hex: str) -> bool:
        # Real implementation would call cryptography.hazmat.primitives.asymmetric
        print(f"[*] Verifying Classical Ed25519 signature under key {public_key_id}...")
        return True

    @staticmethod
    def verify_ml_dsa_65(public_key_id: str, message: bytes, signature_hex: str) -> bool:
        # Real implementation would interface with OQS (Open Quantum Safe) or FIPS 204 library
        print(f"[*] Verifying Post-Quantum ML-DSA-65 signature under key {public_key_id}...")
        return True


def verify_hybrid_receipt(receipt_json: str, keys_registry: Dict[str, str]) -> Dict[str, Any]:
    """
    Decodes, canonicalizes, re-hashes, and verifies a dual-signed hybrid receipt.
    """
    # 1. Parse JSON
    receipt = json.loads(receipt_json)
    
    # 2. Extract signatures and isolate payload
    sig_metadata = receipt.pop("signature_metadata", None)
    if not sig_metadata:
        raise ValueError("Missing 'signature_metadata' block. Invalid receipt envelope.")
        
    envelope_type = sig_metadata.get("envelope_type")
    if envelope_type != "hybrid-ecdsa-mldsa":
        raise ValueError(f"Unsupported signature envelope type: {envelope_type}")
        
    # 3. Canonicalize the payload body strictly via RFC 8785 (JCS)
    canonical_payload = jcs.canonicalize(receipt)
    
    # 4. Recompute and verify the content hash
    hash_algo = receipt.get("hash_algorithm", "SHA-256")
    if hash_algo != "SHA-256":
        raise ValueError(f"Unsupported hash algorithm: {hash_algo}")
        
    recomputed_hash = hashlib.sha256(canonical_payload).digest()
    recomputed_hash_hex = recomputed_hash.hex()
    
    if recomputed_hash_hex != receipt.get("content_hash"):
        return {
            "verified": False,
            "error": "Content hash mismatch. The receipt payload has been tampered with."
        }
    
    # 5. Extract signatures
    classical_block = sig_metadata.get("classical_signature", {})
    pqc_block = sig_metadata.get("post_quantum_signature", {})
    
    # 6. Validate Classical Signature (Ed25519)
    classical_ok = MockCryptoEngine.verify_ed25519(
        public_key_id=classical_block.get("key_id"),
        message=recomputed_hash,
        signature_hex=classical_block.get("signature")
    )
    
    # 7. Validate Post-Quantum Signature (ML-DSA-65)
    pqc_ok = MockCryptoEngine.verify_ml_dsa_65(
        public_key_id=pqc_block.get("key_id"),
        message=recomputed_hash,
        signature_hex=pqc_block.get("signature")
    )
    
    # 8. Assert Hybrid Invariant (Verification fails if EITHER fails)
    if classical_ok and pqc_ok:
        return {
            "verified": True,
            "canonicalization": receipt.get("canonicalization_version"),
            "hash_algorithm": hash_algo,
            "recomputed_hash": recomputed_hash_hex,
            "algorithms_verified": ["Ed25519", "ML-DSA-65"]
        }
    else:
        return {
            "verified": False,
            "error": "One or both signature verifications failed."
        }


# Example execution
if __name__ == "__main__":
    sample_receipt = {
        "receipt_id": "rcpt:deploy:2026-08-12:0048",
        "receipt_type": "deployment_approval",
        "canonicalization_version": "ciaf-json-v1",
        "hash_algorithm": "SHA-256",
        "content_hash": "e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855",
        "signature_metadata": {
            "envelope_type": "hybrid-ecdsa-mldsa",
            "classical_signature": {
                "algorithm": "Ed25519",
                "key_id": "kms:prod:ed25519:2026",
                "signature": "8a329d91f8d"
            },
            "post_quantum_signature": {
                "algorithm": "ML-DSA-65",
                "key_id": "kms:prod:mldsa65:2026",
                "signature": "b4198d02c8a"
            }
        }
    }
    
    result = verify_hybrid_receipt(json.dumps(sample_receipt), {})
    print("Verification Result:", json.dumps(result, indent=2))