> ## Documentation Index > Fetch the complete documentation index at: https://docs.algovoi.co.uk/llms.txt > Use this file to discover all available pages before exploring further. # PQC Substrate Layer > AlgoVoi authored JCS and PQC integration layer: a signature_algorithm open enum, a fail closed verifier discipline, and a cross implementor anchor proof. The PQC substrate layer is the AlgoVoi-authored binding between [the canonicalisation discipline](/canonicalisation-substrate) and post-quantum signature primitives. It binds RFC 8785 JCS canonical bytes to FIPS 204 (ML-DSA-65) and draft FIPS 206 (Falcon-1024) signature schemes under a single `signature_algorithm` open-enum convention with a fail-closed verifier rule. It is published as standalone reference implementations: * **Python**: [`algovoi-substrate-pqc`](https://pypi.org/project/algovoi-substrate-pqc/) (v0.1.2) * **TypeScript**: [`@algovoi/substrate-pqc`](https://www.npmjs.com/package/@algovoi/substrate-pqc) (v0.1.2) Both are Apache-2.0 licensed, browser + Node + Bun + Deno + CPython 3.10+ compatible, and depend on audited upstream PQC libraries (PQClean via `pqcrypto` on Python, `@noble/post-quantum` by Paul Miller on TypeScript). ## Honest layer-split The PQC primitives themselves are **not** AlgoVoi-authored. The substrate convention sits **above** audited upstream PQC implementations: | Layer | Owner | | -------------------------------------------------------------------------- | --------------------------------------------------- | | Falcon-1024 algorithm (FIPS 206 / FN-DSA) | Academic cryptographers + NIST | | Falcon-1024 reference C implementation | PQClean (open-source community) | | Python wrapper around PQClean | `pqcrypto` package (Backbone Authors, Apache-2.0) | | Pure-JS PQC implementation | `@noble/post-quantum` (Paul Miller, MIT) | | Java audit-grade PQC implementation | Bouncy Castle 1.84 (`MLDSASigner` + `FalconSigner`) | | ML-DSA-65 algorithm (FIPS 204) | NIST + academic cryptographers | | JCS canonicalisation rule (RFC 8785) | Anders Rundgren et al. | | AP2 PaymentMandate schema v0.1 | Google agentic-commerce | | **JCS+PQC integration pattern** | **AlgoVoi** | | **`signature_algorithm` open-enum + fail-closed verifier discipline** | **AlgoVoi** | | **Cross-implementor byte-anchor convergence proof methodology** | **AlgoVoi** | | **Multi-language verifier suite (Python + TS + Ruby + PHP + Perl + Java)** | **AlgoVoi** | Every line of attribution is verifiable against the actual code in the [GitHub source](https://github.com/chopmob-cloud/algovoi-substrate-pqc). ## `signature_algorithm` open-enum (12 rows) The 12-row recommended-values registry covers classical, post-quantum, and HMAC families. Case-sensitive lookup per RFC 7517 §4.1. Verifiers MUST treat unknown identifiers as opaque and refuse to verify (fail-closed). | Identifier | Family | Source | Notes | | ------------------- | ------------------ | ------------------------------------ | ------------------------------------------------------------------------------- | | `ECDSA` | Classical | Generic ECDSA | Backward-compat alias; new deployments SHOULD use the specific JOSE identifier. | | `ES256` | Classical | RFC 7518 §3.4 | ECDSA P-256 SHA-256. | | `ES256K` | Classical | RFC 8812 | ECDSA secp256k1 SHA-256. | | `Ed25519` | Classical | RFC 8032 / RFC 8037 | EdDSA Ed25519. | | `ML-DSA-44` | PQC | FIPS 204 / draft-ietf-cose-dilithium | NIST Level 2. | | `ML-DSA-65` | PQC | FIPS 204 / draft-ietf-cose-dilithium | NIST Level 3. | | `ML-DSA-87` | PQC | FIPS 204 / draft-ietf-cose-dilithium | NIST Level 5. | | `Falcon-512` | PQC | FIPS 206 (FN-DSA, pending) | NIST Level 1. | | `Falcon-1024` | PQC | FIPS 206 (FN-DSA, pending) | NIST Level 5. | | `SLH-DSA-SHA2-128s` | PQC stateless-hash | FIPS 205 | SPHINCS+ small. | | `HMAC-SHA-256` | HMAC | RFC 2104 | Internal-channel only. | | `HMAC-SHA-384` | HMAC | RFC 2104 / FIPS 198-1 | PQC-conservative HMAC. | ## Cross-product matrix attestation The substrate-author convention is **producer-verifier symmetric** — signatures emitted in any language verify in any other language for the schemes available in each environment. Demonstrated by a 6-producer × 8-verifier matrix that runs every producer artefact against every available verifier. [Matrix attestation document](https://github.com/chopmob-cloud/algovoi-substrate-pqc/blob/main/_attestations/2026-05-30-cross-product-matrix.md) | Producer ↓ \ Verifier → | **python** | **ts** | **ruby** | **php** | **java** | **perl** | **go** | **rust** | | ----------------------- | ---------- | ------ | -------- | ------- | -------- | --------- | ------ | -------- | | **python** (4 schemes) | 5/5 ✅ | 5/5 ✅ | 4/4 ✅ | 4/4 ✅ | 6/6 ✅ | JCS 2/2 ✅ | 3/3 ✅ | 4/4 ✅ | | **ts** (4 schemes) | 5/5 ✅ | 5/5 ✅ | 4/4 ✅ | 4/4 ✅ | 6/6 ✅ | JCS 2/2 ✅ | 3/3 ✅ | 4/4 ✅ | | **ruby** (2 schemes) | 3/3 ✅ | 3/3 ✅ | 4/4 ✅ | 4/4 ✅ | 4/4 ✅ | JCS 2/2 ✅ | 2/2 ✅ | 2/2 ✅ | | **php** (2 schemes) | 3/3 ✅ | 3/3 ✅ | 4/4 ✅ | 4/4 ✅ | 4/4 ✅ | JCS 2/2 ✅ | 2/2 ✅ | 2/2 ✅ | | **go** (3 schemes) | 4/4 ✅ | 4/4 ✅ | 4/4 ✅ | 4/4 ✅ | 5/5 ✅ | JCS 2/2 ✅ | 3/3 ✅ | 3/3 ✅ | | **rust** (4 schemes) | 5/5 ✅ | 5/5 ✅ | 4/4 ✅ | 4/4 ✅ | 6/6 ✅ | JCS 2/2 ✅ | 3/3 ✅ | 4/4 ✅ | **48/48 cells PASS.** All six producers agreed on canonical SHA-256 `sha256:cc8315f7696c65b2a07eb278de0e45c3149319526c8d443c7e38a17de04c28e0` — six independent JCS canonicalisation implementations producing byte-identical canonical bytes from the same payload. Go produces ES256 + Ed25519 + ML-DSA-65 (no Falcon — no clean pure-Go library without CGo). Rust produces all four schemes (ES256 + Ed25519 + ML-DSA-65 + Falcon-1024) via `p256`, `ed25519-dalek`, `ml-dsa` (RustCrypto FIPS 204), and `pqcrypto-falcon` (PQClean C wrapper). Reproduce locally: ```bash theme={null} git clone https://github.com/chopmob-cloud/algovoi-substrate-pqc cd algovoi-substrate-pqc python scripts/cross_product_matrix.py ``` ## Four audit-grade PQC implementations cross-validated The strongest substrate-author signal: **four independent audit-grade PQC implementations agree** on Falcon-1024 and ML-DSA-65 signatures over identical canonical bytes. ``` PQClean (Python pqcrypto) <--> pqcrypto-falcon / ml-dsa (Rust) | | byte-for-byte byte-for-byte v v @noble/post-quantum (TS) <----> Bouncy Castle (Java) ``` | Implementation | Falcon-1024 | ML-DSA-65 | Notes | | --------------------------------------------------------- | ---------------- | -------------- | -------------------------------------------------------- | | PQClean (Python via `pqcrypto` v0.4.0) | ✓ | ✓ | Reference C implementation | | `@noble/post-quantum` (TypeScript, Paul Miller, MIT) | ✓ | ✓ | Pure JS, audit-grade | | Bouncy Castle 1.84 (Java, `MLDSASigner` + `FalconSigner`) | ✓ (experimental) | ✓ (production) | Established crypto library | | `pqcrypto-falcon` + `ml-dsa` (Rust, RustCrypto / PQClean) | ✓ | ✓ | PQClean C wrapper (Falcon) + pure Rust FIPS 204 (ML-DSA) | Java verifier source at [`verifiers/java/`](https://github.com/chopmob-cloud/algovoi-substrate-pqc/tree/main/verifiers/java). ## PQC cross-implementor contribution The ML-DSA-65 cross-implementor fixture this substrate verifies against was contributed by **PQSafe ([@rayc0](https://github.com/rayc0))** per the [AP2 #250 joint conformance fixture](https://github.com/chopmob-cloud/ap2-pq-conformance). PQSafe is named co-maintainer of the joint conformance repo per the published policy. **Credit is scoped to that ML-DSA-65 contribution only.** Substrate-author work for this layer (the `signature_algorithm` open-enum convention, the JCS+PQC binding pattern, the fail-closed verifier discipline, the byte-anchor convergence proof methodology, the multi-language verifier suite) is AlgoVoi's. ## Multi-language verifier suite In addition to the Python + TypeScript reference impls, the substrate ships verifier scripts in additional scripting languages — all demonstrating that the JCS canonicalisation + classical-signature discipline reproduces in any environment with standard primitives: | Language | Coverage | Source | | ---------------- | ----------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------- | | **Go** 1.22+ | JCS + ES256 + Ed25519 + ML-DSA-65 (circl v1.6.1) | [`verifiers/go/verify/verify.go`](https://github.com/chopmob-cloud/algovoi-substrate-pqc/blob/main/verifiers/go/verify/verify.go) | | **Rust** 1.75+ | JCS + ES256 + Ed25519 + ML-DSA-65 + Falcon-1024 (RustCrypto + pqcrypto) | [`verifiers/rust/src/verify.rs`](https://github.com/chopmob-cloud/algovoi-substrate-pqc/blob/main/verifiers/rust/src/verify.rs) | | **Ruby** 3.4+ | JCS + ES256 + Ed25519 (OpenSSL stdlib) | [`verifiers/ruby/verify.rb`](https://github.com/chopmob-cloud/algovoi-substrate-pqc/blob/main/verifiers/ruby/verify.rb) | | **PHP** 8.4+ | JCS + ES256 + Ed25519 (openssl + sodium) | [`verifiers/php/verify.php`](https://github.com/chopmob-cloud/algovoi-substrate-pqc/blob/main/verifiers/php/verify.php) | | **Perl** 5.38+ | JCS canonical-bytes proof (core modules); ES256 + Ed25519 with CryptX | [`verifiers/perl/verify.pl`](https://github.com/chopmob-cloud/algovoi-substrate-pqc/blob/main/verifiers/perl/verify.pl) | | **Lua** 5.4+ | JCS + ES256 + Ed25519 (lua-openssl) | Pending — install path documented | | **Elixir** 1.17+ | JCS + ES256 + Ed25519 (`:public_key` + `:crypto` Erlang stdlib) | Pending — install path documented | Full cross-runtime matrix (9 verified runtime/language combinations) at the [`docs/CROSS_RUNTIME.md`](https://github.com/chopmob-cloud/algovoi-substrate-pqc/blob/main/docs/CROSS_RUNTIME.md) document. ## Why no scripting-language PQC PQC schemes (Falcon-1024, ML-DSA-65) are **out of scope** for the scripting-language verifiers (Ruby, PHP, Perl, Lua, Elixir). No audit-grade PQC libraries exist in those ecosystems at this time. The alternative — vendoring PQClean's reference C source ourselves and binding via FFI per language — was explicitly considered and rejected in the design phase because: 1. **Falcon-1024 patent encumbrance.** Patent US7308097B2 covers parts of Falcon; FRAND-style royalty-free pledge applies via FIPS 206 standardisation. Vendoring PQClean source makes the substrate package a named redistributor of patent-encumbered code. The current wrap-existing-audited-package design avoids this status. 2. **Per-language FFI maintenance burden.** Each scripting-language FFI binding would require per-language audit + maintenance + patent disclosure surface. Not justified for the substrate-author claim when the canonicalisation + classical-signature coverage already demonstrates substrate is environment-independent. PQC verification is established by the Python + TypeScript + Java implementations, which span the JVM and non-JVM ecosystems with three audit-grade PQC implementations. ## Verifier discipline (fail-closed) > Verifiers MUST treat unknown `signature_algorithm` values as opaque > and refuse to verify. This is the substrate-author fail-closed normative discipline that allows the `signature_algorithm` registry to evolve without breaking schema changes. Implementors MAY declare any value. Verifiers MUST reject unknown values or escalate to a registered extension, rather than guessing. The Python implementation surfaces this rule as `UnknownSignatureAlgorithm` raised from `lookup_signature_algorithm()`. The TypeScript implementation throws `UnknownSignatureAlgorithmError`. Both consistent in semantics. **Empty-signatures invariant (since 0.1.2):** Artefacts with zero declared signatures are never valid even when the canonical SHA is correct. The verifier requires at least one positive verification signal. ## Regulatory alignment Post-quantum migration is moving from "best practice" to "regulatory requirement" across multiple jurisdictions. The PQC substrate is designed against the following frameworks. The substrate provides the cryptographic primitives, the algorithm-class declaration, and the verifier discipline; production deployment additionally requires organisational migration planning, key-management process, and periodic re-assessment. | Framework | What it requires (in scope here) | How the PQC substrate addresses it | | ------------------------------------------------------------------------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | **NIST IR 8547** (Transition to PQ Cryptography Standards, 2025) | Inventory of quantum-vulnerable cryptography, migration plan to NIST PQC standards (FIPS 203 / 204 / 205), prioritisation by data sensitivity. | Algorithm coverage spans the NIST FIPS 204 ML-DSA family (ML-DSA-44 / 65 / 87) and FIPS 206 Falcon family (512 / 1024). The `signature_algorithm` open-enum makes the algorithm declaration machine-readable for inventory tooling. Roadmap entry for FIPS 205 (SLH-DSA-SHA2-128s) is in the registry above. | | **EU DORA** (Digital Operational Resilience Act, applied January 2025) | ICT operational resilience for financial entities, including cryptographic algorithm management and resilience to cryptographic obsolescence. | Fail-closed verifier discipline (unknown algorithms refuse to verify rather than silently downgrade) is the operational-resilience pattern the regulation expects. The `signature_algorithm` declaration enables algorithm-level audit trails across the lifetime of a transaction record. | | **EU Cyber Resilience Act** (CRA, in force 2024, full obligations from 2027) | Cryptographic transparency in software supply chains; ability to disclose algorithm choices to downstream users. | The `signature_algorithm` open-enum is per-signature machine-readable disclosure. The honest layer-split table at the top of this page is per-component upstream-library disclosure suitable for SBOM crypto-bill-of-materials reporting. | | **HKMA AS-04** (Hong Kong Monetary Authority, PQ migration guidance for Authorised Institutions) | AIs to assess PQ-readiness of cryptographic systems including transaction signing, by published HKMA timeline. | NIST FIPS 204 ML-DSA family is the recognised PQ scheme set under HKMA AS-04. The AlgoVoi-authored multi-language verifier suite demonstrates implementation portability across JVM and non-JVM ecosystems. | | **NIST SP 800-208** (stateful hash-based signatures) | XMSS / LMS for code-signing contexts where stateful signing is acceptable. | **Out of scope for this substrate** (FIPS 204 / 206 chosen as the stateless-signature route). Noted here for completeness. | The substrate does not claim compliance certification under any of these frameworks. It provides the cryptographic substrate that a downstream implementer can use to make their own compliance attestation. Auditors evaluating PQ-readiness against any of the above frameworks will find the substrate's algorithm coverage, fail-closed discipline, layer-split disclosure, and cross-implementation byte-for-byte agreement evidence useful as part of a broader compliance posture. ## ES256 interop vs. strict modes (TypeScript) The TypeScript package exports two ES256 verifiers: | Function | `lowS` | Use when | | ------------------- | ----------------- | --------------------------------------------------------------------------------------------- | | `verifyES256` | `false` (interop) | Cross-implementation verification — accepts any valid ECDSA signature regardless of `s` range | | `verifyES256Strict` | `true` (strict) | Malleability-resistant contexts — rejects high-s signatures | `verifyArtefact()` uses `verifyES256` (interop mode) by default so that artefacts produced by Python, Java, or other producers verify cleanly. Call `verifyES256Strict` directly when you need malleability protection. ## Install + quickstart ### Python ```bash theme={null} pip install algovoi-substrate-pqc ``` ```python theme={null} from algovoi_substrate_pqc import ( build_convergence_artefact, generate_falcon_1024_keypair, generate_ml_dsa_65_keypair, sign_ed25519, sign_es256, sign_falcon_1024, sign_ml_dsa_65, verify_artefact, ) # ...build artefact, sign with 4 schemes, verify cross-language ``` ### TypeScript ```bash theme={null} npm install @algovoi/substrate-pqc ``` ```typescript theme={null} import { buildConvergenceArtefact, generateFalcon1024Keypair, generateMLDSA65Keypair, signEd25519, signES256, signFalcon1024, signMLDSA65, verifyArtefact, verifyES256, // interop mode (lowS:false) — use for cross-impl verification verifyES256Strict, // strict mode (lowS:true) — use for malleability protection } from '@algovoi/substrate-pqc'; ``` ### Java (Bouncy Castle) ```bash theme={null} cd verifiers/java bash fetch-deps.sh javac -cp "lib/*" -d out Verify.java java -cp "out;lib/*" Verify path/to/artefact.json ``` ## PQC credential binding and federation layer The PQC substrate is the foundation for two production protocols built above it: * **PQC Credential Binding** — Falcon-1024 / ML-DSA-65 credentials bound to x402 agentic payment authorization. Eliminates long-lived API keys from the payment hot path. Specified in [`draft-hopley-x402-pqc-credential-binding-00`](https://datatracker.ietf.org/doc/draft-hopley-x402-pqc-credential-binding-00/). * **Cross-Issuer ZKP Federation** — composes independently-issued PQC credentials from different issuers into a single composite token without a shared trust root. Specified in [`draft-hopley-x402-federation-zkp-00`](https://datatracker.ietf.org/doc/draft-hopley-x402-federation-zkp-00/). Both protocols are described in the peer-reviewed research paper: **[IACR ePrint 2026/109852](https://eprint.iacr.org/2026/109852)** — *AlgoVoi Agent Trust Bench: Adversarial Evaluation, Post-Quantum Credential Binding, and Cross-Issuer Federation for Agentic Payment Safety*. The implementation packages (`algovoi-federation-validator`, `algovoi-zkp-receipt`) are available under the AlgoVoi Commercial License v1.0. The substrate itself remains Apache 2.0. ## See also * [Canonicalisation substrate](/canonicalisation-substrate) — the JCS RFC 8785 discipline this layer composes with. * [Agent Session Authentication](/agent-session-auth) — the PQC credential exchange flow (ZKP cert → session JWT). * [Substrate authorship and provenance](/substrate-authorship-provenance) — full record of dated AlgoVoi-authored artefacts. * [Adopters Registry](/adopters) — public registry of parties using `urn:x402:canonicalisation:jcs-rfc8785-v1`. * [Conformance vectors](/conformance-vectors) — full corpus + matrix attestations. ## License Apache 2.0. Same as the rest of the AlgoVoi substrate.