GitHub - lecodev-26/nexus-q: Post-quantum cryptographic security engine for protecting data, keys, and identities.

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. Quick navigation 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. Status Capability Qualification 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 and its binding guide. 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. 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. 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. 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. Security model at a glance 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. Area Main components Purpose / boundary Core and primitives nexusq-core, nexusq-kernels, nexusq-ml-kem, nexusq-ml-dsa Core security logic and algorithm-focused crates Application interfaces nexusq, nexusq-cli, nexusq-server Aggregate Rust API, command-line interface, authenticated HTTP service Native integration nexusq-c, nexusq-cpp, nexusq-py C/C++ integration and Python extension/binding 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 Language bindings bindings/ Dart, .NET, Go, Java, Kotlin, PHP, Ruby, Swift and TypeScript/Node.js Performance evidence arena/, BENCHMARKS.md, docs/performance/ Benchmark adapters, methodology, measured reports and historical engineering decisions 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. Overview NEXUS-Q is a post-quantum cryptographic security engine designed to protect: 🔒 Data 🗝 Keys 🪪 Identities Authenticated encryption of files and streams. Full lifecycle management: generation, rotation, revocation, destruction. Digital signatures and verifiable credentials. 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. We do not invent cryptography. Only standardized algorithms and maintained cryptographic libraries; dependency audit status is documented explicitly.

Library-first.

The core is a Rust library; the CLI, SDKs and server are layers on top. 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.

Zeroization.

Secrets are wiped from memory when no longer needed.

Auditability.