{"slug": "the-engineering-around-post-quantum-cryptography-is-as-important", "title": "The engineering around post-quantum cryptography is as important", "summary": "NEXUS-Q v4.1.2, an open-source post-quantum cryptographic engine written in Rust, was released on 2026-10-28 as an \"Audit-Ready Release\" with no production-readiness claim, no FIPS validation and an external audit still pending, according to the project's own release documentation. The release keeps RustCrypto as the default implementation path, with the native ML-KEM/ML-DSA backend remaining experimental and opt-in behind the `native-backend` feature, and requires Rust 1.88 or newer on `main`. The project states its assurance boundary covers security CI, fuzz targets and a documented threat model, and that registry availability is not proof of build provenance for every ecosystem package.", "body_md": "|  | **NEXUS-Q is an open-source post-quantum cryptographic engine written in Rust** | \n\n**Protecting data, keys, and identities with standardized cryptography and an auditable security workflow.**\n\nA plain-language tour of the project lives on the website: [nexus-q.link](https://nexus-q.link).\n\n**Current project status (checked 2026-10-28):** NEXUS-Q v4.1.2 is the current release. Audit-Ready Release. No production-readiness claim, no FIPS validation, external audit pending. Registry availability and release provenance are documented separately; the Go module retains independent v0.x versioning. The native ML-KEM/ML-DSA backend remains experimental and opt-in; RustCrypto remains the default path.\n\n**v4.1.2 release status (2026-10-28):** **Audit-Ready Release. No production-readiness claim, no FIPS validation, external audit pending.** The release evidence and limitations are documented in `docs/V4_RELEASE.md`; registry availability is not proof of build provenance for every ecosystem package.\n\n| Item | Current project position | \n|---|---|\n| Language | Rust, edition 2024 | \n| Current `main` toolchain | Rust 1.88 or newer; see the release-provenance note above before assuming published artifacts match `main` | \n| Cryptography | Standardized classical and post-quantum primitives; see [Cryptography](#cryptography) and[`docs/CRYPTOGRAPHY.md`](https://github.com/lecodev-26/nexus-q/blob/main/docs/CRYPTOGRAPHY.md) | \n| Default implementation path | RustCrypto; the native backend is experimental and opt-in | \n| Interfaces | Rust library, CLI, server, C ABI and language SDKs; availability and packaging vary by ecosystem | \n| License | MIT OR Apache-2.0 | \n| Assurance boundary | Security CI, fuzz targets and documented threat model; no independent external audit or certification claimed | \n\nThis is a quick orientation, not a substitute for the per-module documentation or release provenance. “Available” means the repository has an implemented path; it does not imply independent audit or certification.\n\n| Status | Capability | Qualification | \n|---|---|---|\n| Available | Rust core, CLI, server, vault/storage workflows, policy checks, audit logging and documented SDK bindings | Verify the specific package, target and release status in [Installation](#installation) and its binding guide. | \n| Available | Standardized cryptographic algorithms via the default RustCrypto path, including ML-KEM/ML-DSA capability in the project | Algorithm support at the library level does not mean every CLI command or SDK exposes every operation. | \n| Experimental / opt-in | Native ML-KEM/ML-DSA backend behind `native-backend` | Not enabled by default in core, CLI, server or SDKs; not independently audited. See [native backend notes](https://github.com/lecodev-26/nexus-q/blob/main/docs/performance/NATIVE_BACKEND_FEATURE.md) . | \n| Integration-specific | HSM module and hardware-provider abstractions | Do not infer that a particular HSM, TPM, Secure Element or enclave is supported or provides hardware isolation without checking the relevant adapter and deployment docs. | \n| Planned / target-dependent | Hardware-backed isolation and platform-specific integrations | Treat roadmap entries as plans until an implementation, supported device matrix and CI evidence are linked. | \n\n| Question | Current documented position | Important limit | \n|---|---|---|\n| Which adversaries are considered? | Network attackers and local unprivileged attackers, with trust boundaries detailed in the [threat model](https://github.com/lecodev-26/nexus-q/blob/main/docs/THREAT_MODEL.md) . | A compromised endpoint, privileged attacker or malicious build/release infrastructure can defeat assumptions; consult the full threat model. | \n| What happens if vault files are stolen? | Vault data is encrypted at rest and key material is managed through the vault/key lifecycle. | Protection depends on password strength, correct deployment and the attacker not obtaining unlock secrets or process memory. | \n| What if the device is already compromised? | Zeroization, policy checks and audit controls provide defense-in-depth. | They do not guarantee protection from an attacker controlling the running process, OS or privileged account. | \n| What if a password is lost? | Follow the documented backup and recovery procedures for the configured vault. | Do not assume a password reset or recovery path can recover cryptographic secrets; keep verified backups and test recovery before production use. | \n| Has an external audit or certification been completed? | No independent external audit or FIPS 140-3 / Common Criteria certification is claimed. | Automated tests, fuzzing, CI, benchmarks and package publication are not substitutes for independent review. | \n| Are all dependency advisories resolved? | Dependency scanning is part of the security workflow. | `RUSTSEC-2023-0071` for`rsa` remains a documented exception in[audit configuration](https://github.com/lecodev-26/nexus-q/blob/main/.cargo/audit.toml) and[`deny.toml`](https://github.com/lecodev-26/nexus-q/blob/main/deny.toml) ; review current CI and advisory status. | \n\nThe repository separates the cryptographic core from interfaces, optional services, and language bindings. These names describe repository components, not a claim that every package has identical maturity, platform support, or release provenance. Use the installation table and each binding's own documentation to confirm the package and target you need.\n\n| Area | Main components | Purpose / boundary | \n|---|---|---|\n| Core and primitives | `nexusq-core` ,`nexusq-kernels` ,`nexusq-ml-kem` ,`nexusq-ml-dsa` | Core security logic and algorithm-focused crates | \n| Application interfaces | `nexusq` ,`nexusq-cli` ,`nexusq-server` | Aggregate Rust API, command-line interface, authenticated HTTP service | \n| Native integration | `nexusq-c` ,`nexusq-cpp` ,`nexusq-py` | C/C++ integration and Python extension/binding | \n| Optional services | `nexusq-admin` ,`nexusq-enrollment` ,`nexusq-ha` ,`nexusq-hsm` ,`nexusq-ocsp` ,`nexusq-pki-cluster` ,`nexusq-tsa` ,`nexusq-x509` | Administration, enrollment, high availability, hardware integration and PKI-related modules; consult individual docs for operational scope | \n| Language bindings | `bindings/` | Dart, .NET, Go, Java, Kotlin, PHP, Ruby, Swift and TypeScript/Node.js | \n| Performance evidence | `arena/` ,`BENCHMARKS.md` ,`docs/performance/` | Benchmark adapters, methodology, measured reports and historical engineering decisions | \n\nThe repository already includes visual assets for the architecture flow, project overview and benchmark comparisons. Benchmark visuals are based on the documented measurements; consult the accompanying tables and run-specific notes rather than treating a graphic as a standalone performance guarantee.\n\nNEXUS-Q is a post-quantum cryptographic security engine designed to protect:\n\n| 🔒 Data | 🗝️ Keys | 🪪 Identities | \n|---|---|---|\n| Authenticated encryption of files and streams. | Full lifecycle management: generation, rotation, revocation, destruction. | Digital signatures and verifiable credentials. | \n\nIt is intended as a cryptographic/security engine for applications and servers. The repository also defines hardware-provider abstraction points for future TPM, HSM, Secure Element, enclave and RISC-V integrations; the default software backend does not itself provide hardware isolation.\n\nEvery operation goes through the same building blocks: a password unlocks an encrypted vault (format F-01, atomic writes), keys are managed through their full lifecycle, data is protected with envelope encryption (format F-02), a deny-by-default policy engine gates actions, and security-relevant events go to an HMAC-authenticated audit log with rollback anchoring.\n\n1. **We do not invent cryptography.** Only standardized algorithms and maintained cryptographic libraries; dependency audit status is documented explicitly.\n2. **Library-first.** The core is a Rust library; the CLI, SDKs and server are layers on top.\n3. **Hardware-agnostic boundary.** Hardware-provider interfaces are separated from the software backend; concrete hardware isolation is only claimed when a provider is implemented and tested.\n4. **Zeroization.** Secrets are wiped from memory when no longer needed.\n5. **Auditability.** Auditable security state changes and cryptographic actions are recorded in a tamper-evident, HMAC-authenticated log.\n6. **Security from the ground up.** Threat model and cryptographic rules before code.\n\n| Component | What it is | \n|---|---|\n| `crates/nexusq-core` | The library. All cryptography, vault, key management, identity, policy, storage and hardware abstraction live here. | \n| `crates/nexusq-cli` | The `nexusq` binary. A thin wrapper over the library; no cryptography. | \n| `crates/nexusq-server` | The `nexusq-server` binary and authenticated HTTP service. | \n| `crates/nexusq-c` ·`crates/nexusq-py` | The C SDK and the Python binding. | \n| `bindings/` | Go, PHP and Ruby bindings. | \n| `arena/` | The PQC Benchmark Arena: pinned external implementations and normalized JSONL output. | \n| `fuzz/` ·`artifact-archive/` | Fuzz targets and the archived V1/V2/V3 evidence with SHA-256 manifests. | \n| `docs/` ·`deploy/` ·`examples/` | Documentation, release packaging and C examples. | \n\n**Current `main` build requirements:** Rust 1.88 or newer (edition 2024, matching the current `Cargo.toml` MSRV) and Git. Published packages may have different source provenance and MSRV; check the specific package metadata when targeting an older toolchain. Additional SDK toolchains are only required when building a specific binding (C/C++, Python, Go, Ruby).\n\n**Target platforms:** Linux (x86_64, aarch64); Android / Termux (aarch64); RISC-V (`riscv64gc-unknown-linux-gnu`), build verified; macOS and Windows release builds are validated by the V2 CI/release gate.\n\n| Family | Purpose | Implemented | \n|---|---|---|\n| Randomness | Entropy for keys, nonces and salts | OS CSPRNG, TRNG support with health checks and mixing | \n| Hashing | Digests and commitments | SHA-2, SHA-3 | \n| KDF | Passwords and key material to keys | Argon2id, HKDF | \n| AEAD | Symmetric authenticated encryption | AES-256-GCM, ChaCha20-Poly1305 | \n| KEM | Post-quantum key encapsulation | ML-KEM-768 and ML-KEM-1024, hybrid with X25519 | \n| Signatures | Authenticity | Ed25519, ML-DSA-65, SLH-DSA-SHAKE-128f | \n\nThe reference document is [`docs/CRYPTOGRAPHY.md`](https://github.com/lecodev-26/nexus-q/blob/main/docs/CRYPTOGRAPHY.md). Planned algorithms must not be described as available until they are implemented and tested.\n\n**Completed:**\n\n- Foundation documents, threat model, cryptographic rules.\n- Crypto core: ML-KEM-768 hybrid with X25519, AES-256-GCM, ChaCha20-Poly1305, Ed25519, SHA-2, SHA-3, Argon2id, HKDF.\n- Key management with full lifecycle.\n- Encrypted vault (format F-01) with atomic writes.\n- Envelope encryption (format F-02).\n- Identities with signing, verification, rotation, revocation and signed credentials.\n- Hardware abstraction traits for software, TPM, HSM, Secure Element and RISC-V.\n- TRNG support with health checks and mixing.\n- Cross-compilation to RISC-V verified.\n- Storage: HMAC-authenticated audit log with rollback anchoring, backup bundle, storage DB.\n- Policy engine with deny-by-default.\n- CLI covering vault, key, data, sign, identity, credential and audit commands.\n\nThe benchmark tables below intentionally retain the recorded measurements, historical comparisons, and known caveats. They are real project benchmark results, not illustrative figures. Each dataset has its own context: local diagnostics, hosted-runner release gates, and historical Arena runs must not be compared as if they were one controlled experiment.\n\nFor reproducibility and fuller context, start with the [PQC Benchmark Arena documentation](https://github.com/lecodev-26/nexus-q/blob/main/arena/README.md), the [benchmark index](https://github.com/lecodev-26/nexus-q/blob/main/BENCHMARKS.md), the [V4 release notes](https://github.com/lecodev-26/nexus-q/blob/main/docs/V4_RELEASE.md), and the linked per-run CI artifacts/reports. Hardware, CPU governor, runner environment, sample count, warmups, comparator versions, and aggregation method matter. Latency ratios are operation-specific; there is no composite score here. Lower latency is better, and a benchmark pass is not an end-to-end application performance or security certification claim.\n\nNEXUS-Q is **not presented as a universal performance leader**. In the 2026-10-21 local x86-64 benchmark, the opt-in native backend was compared with the best eligible per-operation comparator using a matched AWS-LC RNG. Six of nine operations beat the comparator on both median and p95; the other three are close to parity: ML-DSA-65 signing (1.063× median / 1.115× p95), ML-KEM-1024 key generation (1.021× / 1.020×), and ML-KEM-768 key generation (1.015× / 1.013×). This is local diagnostic evidence from an Intel Core i3-N305 with the CPU governor set to `powersave`, not a hosted-runner release benchmark or a universal performance claim. The project owner accepted this result as sufficient to complete Issue [#23](https://github.com/lecodev-26/nexus-q/issues/23), treating 1.00× as an ideal target rather than an absolute closure requirement; the remaining deltas are documented in [`docs/performance/ISSUE_23_FINAL_GATE_AUDIT_2026-10-21.md`](https://github.com/lecodev-26/nexus-q/blob/main/docs/performance/ISSUE_23_FINAL_GATE_AUDIT_2026-10-21.md). The default `nexusq-core` build, CLI and SDKs still use RustCrypto for production call paths; the native path is opt-in and experimental. Lower latency is better.\n\n<sub>v4.1.0 stable line, 2026-10-19: official 1.5× median-and-p95 production-path gate (opt-in native backend vs AWS-LC) from the green release CI on the merged v4.1.0 code — three alternating rounds per implementation, pooled medians and nearest-rank p95, 3,000 samples per operation per implementation on an AMD EPYC 7763 CI runner. The full PQC Benchmark Arena run of the same release (241 normalized measurements, eight comparators plus the V1/V1+zeroize/V3 controls) is retained as CI artifacts. Reported without a composite score.</sub>\n\n| Operation | NEXUS-Q | AWS-LC | NEXUS-Q / AWS-LC | \n|---|---|---|---|\n| ML-KEM-768 keygen | 12.90 µs | 12.33 µs | 1.05× | \n| ML-KEM-768 encaps | 12.94 µs | 12.75 µs | 1.01× | \n| ML-KEM-768 decaps | 15.38 µs | 15.43 µs | 1.00× | \n| ML-KEM-1024 keygen | 18.34 µs | 17.85 µs | 1.03× | \n| ML-KEM-1024 encaps | 18.66 µs | 18.56 µs | 1.01× | \n| ML-KEM-1024 decaps | 22.01 µs | 22.19 µs | 0.99× | \n| ML-DSA-65 keygen | 35.79 µs | 40.00 µs | 0.89× | \n| ML-DSA-65 sign | 83.22 µs | 96.57 µs | 0.86× | \n| ML-DSA-65 verify | 33.54 µs | 34.31 µs | 0.98× | \n\n## **v1.0 Arena baseline (historical)**\n\nThe v1 baseline was slower than the fastest mature implementations on the measured ML-KEM and ML-DSA operations; closing that gap was the primary engineering target of the V4 line.\n\n<sub>Final v1.0 Arena run, 2026-10-05: 57 normalized measurements from eight implementations on the same x86_64 Linux CI environment, 20 iterations and 3 warmups. Reported without a composite score. Comparators: AWS-LC, Botan, CIRCL, liboqs, OpenSSL, PQ Code Package and RustCrypto KEMs. Raw measurements are retained as CI artifacts.</sub>\n\n| Operation | NEXUS-Q v1 | Best measured comparator | NEXUS-Q v1 / best | \n|---|---|---|---|\n| ML-KEM-768 keygen | 33.94 µs | AWS-LC, 11.44 µs | 2.97× | \n| ML-KEM-768 encaps | 27.97 µs | AWS-LC, 12.11 µs | 2.31× | \n| ML-KEM-768 decaps | 34.62 µs | AWS-LC, 15.07 µs | 2.30× | \n| ML-KEM-1024 keygen | 53.89 µs | liboqs, 22.60 µs | 2.38× | \n| ML-KEM-1024 encaps | 46.05 µs | liboqs, 22.71 µs | 2.03× | \n| ML-KEM-1024 decaps | 52.14 µs | liboqs, 25.61 µs | 2.04× | \n| ML-DSA-65 keygen | 168.69 µs | AWS-LC, 44.21 µs | 3.82× | \n| ML-DSA-65 sign | 600.73 µs | AWS-LC, 134.75 µs | 4.46× | \n| ML-DSA-65 verify | 101.20 µs | CIRCL, 22.92 µs | 4.42× | \n\n## **V1 vs V2 (same-runner Arena comparison)**\n\nThe final benchmark record does not claim a performance improvement over V1. Corrected Arena runs produced geometric means of 0.885 and 1.0647513576 V2/V1, so performance remains an unresolved investigation item rather than a validated regression or improvement. The latest same-runner comparison measured V2 at +0.22% to +52.37% latency versus V1 across the nine NEXUS-Q operations; ML-DSA-65 signing is the dominant outlier at +52.37%.\n\n| Operation | V1 | V2 | V2/V1 | Difference | \n|---|---|---|---|---|\n| ML-KEM-768 keygen | 49.819 us | 51.185 us | 1.0274 | +2.74% | \n| ML-KEM-768 encaps | 45.081 us | 46.063 us | 1.0218 | +2.18% | \n| ML-KEM-768 decaps | 54.537 us | 55.997 us | 1.0268 | +2.68% | \n| ML-KEM-1024 keygen | 81.264 us | 82.191 us | 1.0114 | +1.14% | \n| ML-KEM-1024 encaps | 72.041 us | 73.221 us | 1.0164 | +1.64% | \n| ML-KEM-1024 decaps | 83.992 us | 84.859 us | 1.0103 | +1.03% | \n| ML-DSA-65 keygen | 283.730 us | 284.344 us | 1.0022 | +0.22% | \n| ML-DSA-65 sign | 620.367 us | 945.226 us | 1.5237 | **+52.37%** | \n| ML-DSA-65 verify | 181.798 us | 181.479 us | 0.9982 | -0.18% | \n\nThese are same-runner reference measurements from the retained Arena JSONL artifacts. The previous corrected run measured 0.885 V2/V1, demonstrating substantial run-to-run variance; V3 therefore begins with profiling and benchmark-variance investigation rather than assuming a single-run regression. See [`docs/V2_PERFORMANCE_RESULTS.md`](https://github.com/lecodev-26/nexus-q/blob/main/docs/V2_PERFORMANCE_RESULTS.md). Performance investigation is intentionally deferred to V3; V2 is not being modified to manufacture a benchmark result.\n\n## **V1 vs V3 (paired investigation)**\n\nThe paired V1/V3 investigation found median increases of +2.70% to +6.33% across the six measured ML-KEM operations in the recorded hosted-runner experiment; conventional ML-DSA verification was +6.40%, key generation +6.82%, and signing median -0.76%. These are observations from one CI runner and ten paired rounds, not universal performance claims. See [`BENCHMARKS.md`](https://github.com/lecodev-26/nexus-q/blob/main/BENCHMARKS.md) and the [forensic report](https://github.com/lecodev-26/nexus-q/blob/main/arena/results/issue-41-v1-v3-latency-root-cause.md).\n\nThe ML-DSA-only zeroize control does not prove SHA3/SHAKE zeroization is the cause of the ML-KEM latency delta. Issue #41 was closed by explicit project decision: V1 prioritizes speed, while V3 retains security hardening and accepts the observed performance cost.\n\n## **V4.1.0 stable line (Arena run and production-path gate)**\n\nThe v4.1.0 stable line release was validated on `main` with the full PQC Benchmark Arena and the official 1.5× median-and-p95 production-path gate; both are green on the release code (a post-merge compile fix for the pinned Rust 1.85.1 release toolchain landed as [PR #57](https://github.com/lecodev-26/nexus-q/pull/57)).\n\n**Arena run (2026-10-19, commit [`70152eb`](https://github.com/lecodev-26/nexus-q/commit/70152ebcf92c7edfa97c99c5f767a43ecce1aa00)):** 241 normalized measurements on the same `ubuntu-24.04` x86_64 CI environment, 20 iterations and 3 warmups per operation. Comparators: AWS-LC (`ec05f25`), Botan 3.13.0, OpenSSL 3.5.9, CIRCL 1.6.4, RustCrypto KEMs, liboqs 0.16.0 and PQ Code Package, plus the retained V1 / V1+zeroize / V3 controls. Raw JSONL measurements are retained as [CI artifacts of the Arena run](https://github.com/lecodev-26/nexus-q/actions/runs/39186079459); reported without a composite score.\n\n**Production-path gate (native backend vs AWS-LC, three alternating rounds per implementation, pooled medians and nearest-rank p95, 3,000 samples per operation per implementation):** all nine operations passed the unchanged 1.5× median-and-p95 gate on the merged release code ([gate run](https://github.com/lecodev-26/nexus-q/actions/runs/39182674176)).\n\n| Operation | NEXUS-Q median | NEXUS-Q p95 | AWS-LC median | Median ratio | p95 ratio | Gate | \n|---|---|---|---|---|---|---|\n| ML-KEM-768 keygen | 12.90 µs | 13.38 µs | 12.33 µs | 1.046 | 1.041 | pass | \n| ML-KEM-768 encaps | 12.94 µs | 13.00 µs | 12.75 µs | 1.015 | 1.013 | pass | \n| ML-KEM-768 decaps | 15.38 µs | 15.44 µs | 15.43 µs | 0.997 | 0.994 | pass | \n| ML-KEM-1024 keygen | 18.34 µs | 18.86 µs | 17.85 µs | 1.028 | 1.025 | pass | \n| ML-KEM-1024 encaps | 18.66 µs | 18.76 µs | 18.56 µs | 1.005 | 0.985 | pass | \n| ML-KEM-1024 decaps | 22.01 µs | 22.10 µs | 22.19 µs | 0.992 | 0.977 | pass | \n| ML-DSA-65 keygen | 35.79 µs | 36.62 µs | 40.00 µs | 0.895 | 0.885 | pass | \n| ML-DSA-65 sign | 83.22 µs | 235.40 µs | 96.57 µs | 0.862 | 0.846 | pass | \n| ML-DSA-65 verify | 33.54 µs | 34.01 µs | 34.31 µs | 0.978 | 0.976 | pass | \n\nThese are single-runner CI measurements on an AMD EPYC 7763 hosted runner, not universal performance claims. The native backend remains experimental and opt-in; the default `nexusq-core` build, the CLI and the SDKs still use RustCrypto for production call paths. See [`docs/performance/NATIVE_BACKEND_FEATURE.md`](https://github.com/lecodev-26/nexus-q/blob/main/docs/performance/NATIVE_BACKEND_FEATURE.md) and [`docs/V4_RELEASE.md`](https://github.com/lecodev-26/nexus-q/blob/main/docs/V4_RELEASE.md).\n\n| Line | Reference | Current meaning | Status | \n|---|---|---|---|\n| V4.1.2 | [Current published release](https://github.com/lecodev-26/nexus-q/releases/tag/v4.1.2) | Audit-Ready Release. No production-readiness claim, no FIPS validation, external audit pending. | **Current release** | \n| V4.1.1 (historical) | [`v4.1.1`](https://github.com/lecodev-26/nexus-q/releases/tag/v4.1.1) | Historical release; registry availability and provenance have known limitations | **Historical; independent external audit remains open** | \n| V4.1 | [`v4.1.0`](https://github.com/lecodev-26/nexus-q/releases/tag/v4.1.0) ·`main` | Previous stable line release: opt-in native-backend production-path wiring | Historical release; independent external audit remains pending (Phase 21) | \n| V4 | [`v4-engineering-2026-10-16`](https://github.com/lecodev-26/nexus-q/tree/v4-engineering-2026-10-16) ·`nexusqv4` | Experimental native backend and performance work | Engineering snapshot (pre-release) | \n| V3 | [`v3-engineering-2026-10-09`](https://github.com/lecodev-26/nexus-q/releases/tag/v3-engineering-2026-10-09) ·`nexusqv3` | Hardened implementation and benchmark evidence | Engineering release | \n| V2 | [`v2.0.0`](https://github.com/lecodev-26/nexus-q/releases/tag/v2.0.0) ·`nexusqv2` | Security/correctness engineering line | Frozen | \n| V1 | [`v1.0.0`](https://github.com/lecodev-26/nexus-q/releases/tag/v1.0.0) | Original frozen baseline | Historical engineering baseline | \n\n## **V3 engineering release and V4 snapshot**\n\nV3 consolidates the hardened implementation, reproducible PQC Benchmark Arena, dependency/profile diagnostics, corrected benchmark sampling and archived evidence. Its GitHub release is an engineering release, not a claim of independent audit, certification, or registry publication. V1/V2/V3 artifacts and checksums are indexed in [`artifact-archive/README.md`](https://github.com/lecodev-26/nexus-q/blob/main/artifact-archive/README.md).\n\nV4 is now represented by the `v4-engineering-2026-10-16` engineering tag and is integrated into `main`. The native backend and its benchmark harness are present, and the official 1.5× median-and-p95 gate passed in the reviewed CI evidence. PR [#55](https://github.com/lecodev-26/nexus-q/pull/55) wires the backend into `nexusq-core` behind an explicitly opt-in `native-backend` feature; the default build and all SDKs still use RustCrypto, the feature is not enabled by default anywhere, and the production-path benchmark passed the unchanged 1.5× median-and-p95 gate. It remains experimental and is not independently audited; the Phase 21 external audit is still open. The former Issue #48 tracking item is closed; its checklist is retained as historical engineering evidence under [`docs/performance/`](https://github.com/lecodev-26/nexus-q/blob/main/docs/performance).\n\n## **V2.0.0 and V1.0 status**\n\nThe v2 engineering line is frozen on `nexusqv2` at version `2.0.0`. V2 preserves the v1 security model while adding the completed performance, correctness/interoperability, security/fuzzing, backend-strategy and release gates. The GitHub V2.0.0 engineering release is historical; crates.io, PyPI and other SDK registries remain separate publication operations. See [`docs/V2_ROADMAP.md`](https://github.com/lecodev-26/nexus-q/blob/main/docs/V2_ROADMAP.md), [` docs/V2_RELEASE.md`](https://github.com/lecodev-26/nexus-q/blob/main/docs/V2_RELEASE.md) and [` docs/V2_BENCHMARK_BASELINE.md`](https://github.com/lecodev-26/nexus-q/blob/main/docs/V2_BENCHMARK_BASELINE.md).\n\nThe v1.0 engineering baseline is complete and intentionally frozen. The final CI/Arena evidence established a reproducible reference point for correctness, security gates, deployment, documentation and PQC performance. The v1 baseline is **not presented as a performance leader**, and no unsupported production-certification or independent-audit claim is made. External registry/package publication is intentionally deferred. See [`BENCHMARKS.md`](https://github.com/lecodev-26/nexus-q/blob/main/BENCHMARKS.md) and [` docs/ROADMAP.md`](https://github.com/lecodev-26/nexus-q/blob/main/docs/ROADMAP.md).\n\nFrom the repository root, with Rust 1.88+ installed:\n\n```\n# build the workspace\ncargo build --workspace --release\n\n# create and inspect a vault\n./target/release/nexusq vault create ./example.nqv\n./target/release/nexusq vault status ./example.nqv\n./target/release/nexusq health\n\n# generate a signing key (prefer --password-file over typing a password)\n./target/release/nexusq key generate ./example.nqv --algorithm ed25519 --purpose sign --password-file ./password.txt\n\n# encrypt and decrypt data\n./target/release/nexusq data encrypt ./example.nqv --key-id <key-id> ./secret.txt\n./target/release/nexusq data decrypt ./example.nqv ./secret.txt.nqx ./secret.out\n```\n\nTreat `password.txt` as a secret: restrict its permissions and never commit it. For development, `cargo build` and `cargo test` work as usual, and the CLI binary is at `target/debug/nexusq`. To build for RISC-V see [` docs/CROSS_COMPILE.md`](https://github.com/lecodev-26/nexus-q/blob/main/docs/CROSS_COMPILE.md). The signing-key example above explicitly uses Ed25519 (classical, not post-quantum); see [`docs/user/CLI.md`](https://github.com/lecodev-26/nexus-q/blob/main/docs/user/CLI.md) for the CLI-supported algorithms and do not infer that every library-level ML-KEM/ML-DSA operation is exposed through the same CLI workflow. The commands are an orientation: create the password file and input file first, and substitute the actual key ID printed by key generation for `<key-id>`.\n\n**Release deployment:**\n\n```\ncargo build --workspace --release\n./deploy/package-release.sh\n```\n\nThe generated archive contains the CLI, server, non-secret configuration example, deployment documentation, and SHA-256 manifests. It does not contain production tokens, vaults, private keys, or logs. For server installation and operations see [`docs/DEPLOYMENT.md`](https://github.com/lecodev-26/nexus-q/blob/main/docs/DEPLOYMENT.md) and [` docs/SERVER.md`](https://github.com/lecodev-26/nexus-q/blob/main/docs/SERVER.md).\n\nNEXUS-Q v4.1.2 is the current Audit-Ready Release. The table below lists installation targets and the latest published package versions. The Go module and experimental native backend keep independent version lines. The auxiliary Rust crates listed at v4.1.1 remain available at that stable published version; they were not republished as v4.1.2 because this release closeout contains documentation changes only and does not require new crate versions. This is intentional, not an availability error. Registry availability does not prove build provenance for every ecosystem; the earlier v4.1.1 provenance caveat remains historical.\n\n| Channel / package | Install | \n|---|---|\n| Rust library (all-in-one) | `cargo add nexusq@4.1.2` —[crates.io](https://crates.io/crates/nexusq) | \n| Rust core library | `cargo add nexusq-core@4.1.2` —[crates.io](https://crates.io/crates/nexusq-core) | \n| Rust kernels | `cargo add nexusq-kernels@4.1.2` —[crates.io](https://crates.io/crates/nexusq-kernels) | \n| Rust ML-KEM | `cargo add nexusq-ml-kem@4.1.2` —[crates.io](https://crates.io/crates/nexusq-ml-kem) | \n| Rust ML-DSA | `cargo add nexusq-ml-dsa@4.1.2` —[crates.io](https://crates.io/crates/nexusq-ml-dsa) | \n| Rust native backend (experimental, opt-in) | `cargo add nexusq-native-backend@0.1.0` —[crates.io](https://crates.io/crates/nexusq-native-backend) ; not enabled by default | \n| Rust C SDK | `cargo add nexusq-c@4.1.2` —[crates.io](https://crates.io/crates/nexusq-c) | \n| Rust Python binding crate | `cargo add nexusq-py@4.1.2` —[crates.io](https://crates.io/crates/nexusq-py) | \n| Rust CLI | `cargo install nexusq-cli --version 4.1.2` —[crates.io](https://crates.io/crates/nexusq-cli) | \n| Rust server | `cargo install nexusq-server --version 4.1.2` —[crates.io](https://crates.io/crates/nexusq-server) | \n| Rust admin module | `cargo add nexusq-admin@4.1.1` —[crates.io v4.1.1](https://crates.io/crates/nexusq-admin/4.1.1) (latest published version; no new package was needed for this documentation-only release). | \n| Rust PKI cluster module | `cargo add nexusq-pki-cluster@4.1.1` —[crates.io v4.1.1](https://crates.io/crates/nexusq-pki-cluster/4.1.1) (latest published version; no new package was needed for this documentation-only release). | \n| Rust HSM integration | `cargo add nexusq-hsm@4.1.1` —[crates.io v4.1.1](https://crates.io/crates/nexusq-hsm/4.1.1) (latest published version; no new package was needed for this documentation-only release). | \n| Rust enrollment module | `cargo add nexusq-enrollment@4.1.1` —[crates.io v4.1.1](https://crates.io/crates/nexusq-enrollment/4.1.1) (latest published version; no new package was needed for this documentation-only release). | \n| Rust HA module | `cargo add nexusq-ha@4.1.1` —[crates.io v4.1.1](https://crates.io/crates/nexusq-ha/4.1.1) (latest published version; no new package was needed for this documentation-only release). | \n| Rust OCSP module | `cargo add nexusq-ocsp@4.1.1` —[crates.io v4.1.1](https://crates.io/crates/nexusq-ocsp/4.1.1) (latest published version; no new package was needed for this documentation-only release). | \n| Rust TSA module | `cargo add nexusq-tsa@4.1.1` —[crates.io v4.1.1](https://crates.io/crates/nexusq-tsa/4.1.1) (latest published version; no new package was needed for this documentation-only release). | \n| Rust X.509 module | `cargo add nexusq-x509@4.1.1` —[crates.io v4.1.1](https://crates.io/crates/nexusq-x509/4.1.1) (latest published version; no new package was needed for this documentation-only release). | \n| Python | `pip install nexusq==4.1.2` —[PyPI](https://pypi.org/project/nexusq/4.1.2/) ; source distribution only, no platform wheel | \n| TypeScript / Node.js | `npm install nexusq@4.1.2` —[npm](https://www.npmjs.com/package/nexusq/v/4.1.2) | \n| Java | Maven `io.github.lecodev-26:nexusq:4.1.2` — POM, JAR, sources and Javadocs verified on Maven Central —[artifact](https://repo.maven.apache.org/maven2/io/github/lecodev-26/nexusq/4.1.2/) ·[Sonatype page](https://central.sonatype.com/artifact/io.github.lecodev-26/nexusq) | \n| Kotlin | Maven `io.github.lecodev-26:nexusq-kotlin:4.1.2` — POM, JAR, sources and Javadocs verified on Maven Central —[artifact](https://repo.maven.apache.org/maven2/io/github/lecodev-26/nexusq-kotlin/4.1.2/) ·[Sonatype page](https://central.sonatype.com/artifact/io.github.lecodev-26/nexusq-kotlin) | \n| C# / .NET | `dotnet add package Nexusq --version 4.1.2` — NuGet version index and downloadable`.nupkg` verified, including native runtime assets —[NuGet](https://www.nuget.org/packages/Nexusq/4.1.2) | \n| Swift / SwiftPM | `.package(url: \"https://github.com/lecodev-26/nexus-q.git\", from: \"4.1.2\")` , product`Nexusq` — current release tag[`v4.1.2`](https://github.com/lecodev-26/nexus-q/releases/tag/v4.1.2) . The v4.1.1 tag/provenance issue is historical and documented in`docs/V4_RELEASE.md` . | \n| Dart / Flutter | `dart pub add nexusq:^4.1.2` —[pub.dev](https://pub.dev/packages/nexusq/versions/4.1.2) | \n| Go | `go get github.com/lecodev-26/nexus-q/bindings/go/nexusq@v0.1.0` — independent Go module version`v0.1.0` ; native runtime pin`4.1.2` verified against the published release manifest and SHA-256 checksums —[pkg.go.dev](https://pkg.go.dev/github.com/lecodev-26/nexus-q/bindings/go/nexusq) | \n| PHP | `composer require lecodev-26/nexusq:4.1.2` — Packagist v4.1.2 endpoint verified —[Packagist](https://packagist.org/packages/lecodev-26/nexusq) | \n| Ruby | `gem install nexusq -v 4.1.2` — RubyGems v4.1.2 endpoint verified —[RubyGems](https://rubygems.org/gems/nexusq/versions/4.1.2) | \n\nThe following coordinates are published and can be used directly:\n\n```\n<dependency>\n  <groupId>io.github.lecodev-26</groupId>\n  <artifactId>nexusq</artifactId>\n  <version>4.1.2</version>\n</dependency>\n// Gradle Kotlin DSL\nimplementation(\"io.github.lecodev-26:nexusq:4.1.2\")\nimplementation(\"io.github.lecodev-26:nexusq-kotlin:4.1.2\")\n```\n\n- The Go, PHP, Ruby, TypeScript, Java (JNA), Kotlin (JNA) and Dart bindings are thin FFI wrappers over the C SDK (`libnexusq` ). Follow the language-specific setup instructions in`bindings/` and[`docs/NATIVE_RUNTIME_PACKAGING.md`](https://github.com/lecodev-26/nexus-q/blob/main/docs/NATIVE_RUNTIME_PACKAGING.md) ; platform support and automatic runtime download behavior differ by SDK.\n- The Python package is a native extension module built from `crates/nexusq-py` (PyO3). The PyPI 4.1.2 upload currently contains an sdist, not a platform wheel.\n- The C#/.NET binding uses P/Invoke and the Swift binding links the C SDK through a Swift Package Manager system-library target. Ensure the native library is available as described in the relevant binding docs.\n- The C SDK is consumable directly from C and C++; build it from source with `cargo build -p nexusq-c --release` or use the C SDK package.\n- The GitHub release archive ships the CLI/server and native runtime assets; it is not a replacement for installing the C SDK development headers.\n- Registry availability is a distribution channel, not a security validation claim. See the security and assurance section below.\n\nUser-facing documentation starts at [`docs/user/README.md`](https://github.com/lecodev-26/nexus-q/blob/main/docs/user/README.md), with a task-oriented [getting started guide](https://github.com/lecodev-26/nexus-q/blob/main/docs/user/GETTING_STARTED.md), [installation instructions](https://github.com/lecodev-26/nexus-q/blob/main/docs/user/INSTALLATION.md), [CLI guide](https://github.com/lecodev-26/nexus-q/blob/main/docs/user/CLI.md), [SDK guide](https://github.com/lecodev-26/nexus-q/blob/main/docs/user/SDK.md), and [troubleshooting guide](https://github.com/lecodev-26/nexus-q/blob/main/docs/user/TROUBLESHOOTING.md). Technical and reference documentation lives in `docs/`:\n\n| Document | Covers | \n|---|---|\n| [ARCHITECTURE](https://github.com/lecodev-26/nexus-q/blob/main/docs/ARCHITECTURE.md) | System design | \n| [THREAT_MODEL](https://github.com/lecodev-26/nexus-q/blob/main/docs/THREAT_MODEL.md) | What we protect against | \n| [CRYPTOGRAPHY](https://github.com/lecodev-26/nexus-q/blob/main/docs/CRYPTOGRAPHY.md) | Algorithms and rules | \n| [KEY_MANAGEMENT](https://github.com/lecodev-26/nexus-q/blob/main/docs/KEY_MANAGEMENT.md) | Key lifecycle | \n| [SECURITY_MODEL](https://github.com/lecodev-26/nexus-q/blob/main/docs/SECURITY_MODEL.md) | Security guarantees | \n| [STORAGE](https://github.com/lecodev-26/nexus-q/blob/main/docs/STORAGE.md) | Persistent formats | \n| [API](https://github.com/lecodev-26/nexus-q/blob/main/docs/API.md) | Public interfaces | \n| [POLICY](https://github.com/lecodev-26/nexus-q/blob/main/docs/POLICY.md) | Access control engine | \n| [SECURE_BOOT](https://github.com/lecodev-26/nexus-q/blob/main/docs/SECURE_BOOT.md) | Secure and measured boot | \n| [CROSS_COMPILE](https://github.com/lecodev-26/nexus-q/blob/main/docs/CROSS_COMPILE.md) | Cross-compilation guide | \n| [ROADMAP](https://github.com/lecodev-26/nexus-q/blob/main/docs/ROADMAP.md) | The phased plan | \n| [adr/](https://github.com/lecodev-26/nexus-q/blob/main/docs/adr) | Architecture decision records | \n| [ci-pipeline.md](https://github.com/lecodev-26/nexus-q/blob/main/docs/ci-pipeline.md) | CI phases, validation and workflow intent | \n| [performance/](https://github.com/lecodev-26/nexus-q/blob/main/docs/performance) | Benchmark methodology, native-backend notes and historical decisions | \n| [security/](https://github.com/lecodev-26/nexus-q/blob/main/docs/security) | Security design assessments and follow-up decisions | \n\nV1–V4 are engineering version lines/snapshots, not proof of production readiness. A GitHub release does not imply an independent security audit, certification, FIPS validation, or production readiness; the same applies to registry publication, which is a distribution channel and not a validation claim. The V4 native backend remains experimental and opt-in; it is wired into `nexusq-core` behind the `native-backend` feature but is not enabled by default in the core, CLI, server, or SDKs. The performance gate result applies to the benchmarked backend and must not be read as an end-to-end application performance claim. Check [current `main` CI](https://github.com/lecodev-26/nexus-q/actions) before relying on any validation statement.\n\n| ✅ Claimed and evidenced | ❌ Not claimed | \n|---|---|\n| Standardized algorithms through maintained libraries | Independent external audit | \n| Secrets zeroized when no longer needed | FIPS validation or Common Criteria certification | \n| Tamper-evident, HMAC-authenticated audit log | Formal verification | \n| Deny-by-default policy engine | Production readiness | \n| Security CI, SDK CI, benchmark CI and fuzz targets | Registry publication as an audit or production-readiness endorsement | \n| Published threat model and security model | Hardware isolation from the default software backend | \n\nReport suspected vulnerabilities privately through GitHub Security Advisories. See [`SECURITY.md`](https://github.com/lecodev-26/nexus-q/blob/main/SECURITY.md).\n\nIssues, reproducible bug reports, documentation improvements, and focused pull requests are welcome. Before opening a change:\n\n1. \nRead the [architecture](https://github.com/lecodev-26/nexus-q/blob/main/docs/ARCHITECTURE.md) ,[threat model](https://github.com/lecodev-26/nexus-q/blob/main/docs/THREAT_MODEL.md) ,[cryptographic rules](https://github.com/lecodev-26/nexus-q/blob/main/docs/CRYPTOGRAPHY.md) , and[security policy](https://github.com/lecodev-26/nexus-q/blob/main/SECURITY.md) relevant to the change.\n2. \nKeep cryptographic primitives delegated to established libraries; do not introduce home-grown cryptography or silently change serialized formats.\n3. \nAdd or update tests and documentation alongside behavior changes. For performance work, include reproducible measurements and preserve the benchmark conditions and raw evidence.\n4. \nRun the relevant local checks before submitting. A useful baseline for Rust changes is: \n\n```\ncargo fmt --all -- --check\ncargo test --workspace\ncargo build --workspace --release\n```\n\n Run the checks applicable to the crates and SDKs you changed; CI remains the authoritative check for the full supported matrix.\n5. \nDescribe security-impacting changes and compatibility implications clearly in the pull request. Never include secrets, private keys, vault contents, production credentials, or sensitive logs.\n\nPlease report suspected vulnerabilities privately using the process in [`SECURITY.md`](https://github.com/lecodev-26/nexus-q/blob/main/SECURITY.md), rather than publishing exploitable details in a public issue.\n\nDual-licensed under your choice of the [MIT License](https://github.com/lecodev-26/nexus-q/blob/main/LICENSE-MIT) or the [Apache License 2.0](https://github.com/lecodev-26/nexus-q/blob/main/LICENSE-APACHE). This follows the Rust ecosystem convention (the same choice as Rust, Tokio and Serde).", "url": "https://wpnews.pro/news/the-engineering-around-post-quantum-cryptography-is-as-important", "canonical_source": "https://github.com/lecodev-26/nexus-q", "published_at": "2026-11-04 12:03:55+00:00", "updated_at": "2026-11-04 12:21:18.721292+00:00", "lang": "en", "topics": ["ai-safety"], "entities": ["NEXUS-Q", "Rust", "RustCrypto", "ML-KEM", "ML-DSA", "FIPS"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/the-engineering-around-post-quantum-cryptography-is-as-important", "markdown": "https://wpnews.pro/news/the-engineering-around-post-quantum-cryptography-is-as-important.md", "text": "https://wpnews.pro/news/the-engineering-around-post-quantum-cryptography-is-as-important.txt", "jsonld": "https://wpnews.pro/news/the-engineering-around-post-quantum-cryptography-is-as-important.jsonld"}}