The engineering around post-quantum cryptography is as important

Protecting data, keys, and identities with standardized cryptography and an auditable security workflow. A plain-language tour of the project lives on the website: nexus-q.link.

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.

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.

Start here Explore deeper

Overview and design · Cryptography · Quick start Architecture · Threat model · Security model

Benchmarks and measured results · Installation Benchmark Arena and methodology · Benchmark index · Performance reports

Project status and versions · Security and assurance Roadmap · Release notes · Security policy

Documentation index · Contributing · License Website · Releases · Discussions

Project at a glance

Item Current project position

Language Rust, edition 2024

Current main toolchain Rust 1.88 or newer; see the release-provenance note above before assuming published artifacts match main

Cryptography Standardized classical and post-quantum primitives; see Cryptography and docs/CRYPTOGRAPHY.md

Default implementation path RustCrypto; the native backend is experimental and opt-in

Interfaces Rust library, CLI, server, C ABI and language SDKs; availability and packaging vary by ecosystem

License MIT OR Apache-2.0

Assurance boundary Security CI, fuzz targets and documented threat model; no independent external audit or certification claimed

Capability and maturity matrix

This 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.

Question Current documented position Important limit

Which adversaries are considered? Network attackers and local unprivileged attackers, with trust boundaries detailed in the threat model. A compromised endpoint, privileged attacker or malicious build/release infrastructure can defeat assumptions; consult the full threat model.

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.

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.

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.

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.

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 and deny.toml; review current CI and advisory status.

Modules and SDKs

The 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.

The 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.

NEXUS-Q is a post-quantum cryptographic security engine designed to protect:

It 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.

Every 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.

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).

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.

Family Purpose Implemented

Randomness Entropy for keys, nonces and salts OS CSPRNG, TRNG support with health checks and mixing

Hashing Digests and commitments SHA-2, SHA-3

KDF Passwords and key material to keys Argon2id, HKDF

AEAD Symmetric authenticated encryption AES-256-GCM, ChaCha20-Poly1305

KEM Post-quantum key encapsulation ML-KEM-768 and ML-KEM-1024, hybrid with X25519

Signatures Authenticity Ed25519, ML-DSA-65, SLH-DSA-SHAKE-128f

The reference document is docs/CRYPTOGRAPHY.md. Planned algorithms must not be described as available until they are implemented and tested.

The 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.

For reproducibility and fuller context, start with the PQC Benchmark Arena documentation, the benchmark index, the V4 release notes, 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.

NEXUS-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, 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. 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.

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.

The 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.

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.

The 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%.

These 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. Performance investigation is intentionally deferred to V3; V2 is not being modified to manufacture a benchmark result.

The 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 and the forensic report.

The 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.

The 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).

Arena run (2026-10-19, commit 70152eb): 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; reported without a composite score.

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).

These 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 defaul