NEXUS-Q — Post-quantum cryptographic security engine

V3 engineering release · Oct 9, 2026 · no independent audit impliedPost-quantum security, built in the open. NEXUS-Q is a Rust engine for protecting data, keys and identities with ML-KEM, ML-DSA and a tamper-evident audit log, plus an honest account of what it does and does not prove. This page explains the whole project, so you do not have to audit the repository to understand it. Built for developers and teams who embed cryptography in applications and servers that must protect secrets for the long term. Maintained by lecodev-26 · contributors 5Rust crates in the workspace5SDK languages: C, Python, Go, PHP, Ruby8implementations in the PQC Benchmark Arena57normalized Arena measurements / overview What is NEXUS-Q? A post-quantum cryptographic security engine. It is a library first: a Rust core that does all the cryptography, with a command line, an HTTP server and language SDKs layered on top. It is meant to be embedded in applications and servers that need to protect secrets for the long term. DataAuthenticated encryption of files and streams, with envelope encryption (format F-02) so payloads are protected under a key that is itself protected. KeysThe full key lifecycle: generation, rotation, revocation and destruction, stored in an encrypted vault (format F-01) with atomic writes. IdentitiesDigital signatures, signature verification, identity rotation and revocation, and signed verifiable credentials. Why post-quantum?Large quantum computers would break the public-key schemes in wide use today (RSA, elliptic curves), and data recorded now could be decrypted later. NEXUS-Q uses the NIST-standardized lattice algorithms ML-KEM and ML-DSA, and pairs the key exchange with classical X25519 as a hybrid. The golden ruleWe do not invent cryptography. Every primitive is a standardized algorithm implemented by a maintained library. Deviations need a written architecture decision record. The project also states plainly that it does not claim every dependency has been independently audited. / how it works From password to protected data Every operation goes through the same building blocks. Policy decides who may act, the vault guards the keys, and security-relevant events are written to an audit log that detects tampering. 01Unlock the vaultA password goes through Argon2id to unlock the encrypted vault. The vault holds keys at rest and is written atomically. 02Manage keysGenerate, rotate, revoke and destroy keys. Secrets are zeroized in memory when they are no longer needed. 03Encrypt or signHybrid ML-KEM + X25519 for key exchange, AES-256-GCM or ChaCha20-Poly1305 for data, Ed25519, ML-DSA-65 or SLH-DSA for signatures. 04Enforce policyA deny-by-default policy engine decides which actions are allowed before they happen. 05Audit everythingAn HMAC-authenticated audit log with rollback anchoring makes tampering and truncation detectable. Library firstThe core is a Rust library. The CLI, the server and the SDKs are thin layers on top and contain no cryptography of their own. Hardware-agnostic boundaryProvider traits exist for software, TPM, HSM, Secure Element and RISC-V. Hardware isolation is only claimed when a provider is implemented and tested. The default software backend does not provide it. Security from the ground upThe threat model and the cryptographic rules were written before the code, and they are part of the repository. / architecture What is in the repository A Cargo workspace of five Rust crates, plus bindings for other languages and a reproducible benchmark arena. ComponentWhat it is nexusq-coreThe library. All cryptography, vault, key management, identity, policy, storage and hardware abstraction live here. nexusq-cliThe nexusq binary: vault, key, data, sign, identity, credential and audit commands. A thin wrapper over the library. nexusq-serverThe nexusq-server binary and authenticated HTTP service, with health, readiness and Prometheus-style metrics endpoints. nexusq-c · nexusq-pyThe C SDK and the Python binding, built on the core library. bindings/go · php · rubyLanguage bindings covered by a dedicated SDK CI workflow. arena/The PQC Benchmark Arena: pinned external implementations, a normalized JSONL protocol and retained CI artifacts. fuzz/ · artifact-archive/Fuzz targets, and the archived V1/V2/V3 evidence with SHA-256 manifests. TargetsLinux x86_64 and aarch64, Android/Termux aarch64, and RISC-V (riscv64gc) with a verified build. RequirementsRust 1.85 or newer (edition 2024) and Git. SDK toolchains are only needed for the binding you build. StorageEncrypted vault, envelope format, backup bundles and a storage database, all with documented formats. ObservabilityRequest IDs, aggregate metrics, health and readiness probes. Secrets are kept out of logs. / cryptography Six families, nothing else The core is only allowed to use six families of primitives. Anything outside them, such as raw RSA or custom MACs, is forbidden by the project's own rules. FamilyPurposeImplemented RandomnessEntropy for keys, nonces and saltsOS CSPRNG, plus TRNG support with health checks and mixing HashingDigests and commitmentsSHA-2, SHA-3 KDFPasswords and key material to keysArgon2id, HKDF AEADSymmetric authenticated encryptionAES-256-GCM, ChaCha20-Poly1305 KEMPost-quantum key encapsulationML-KEM-768 and ML-KEM-1024, hybrid with X25519 SignaturesAuthenticity and non-repudiationEd25519, ML-DSA-65, SLH-DSA-SHAKE-128f Planned algorithms are never described as available until they are implemented and tested. The reference document is docs/CRYPTOGRAPHY.md. / benchmarks Performance, reported honestly NEXUS-Q is not a performance leader, and the project says so. The numbers below come from the repository's own benchmark records. They are the baseline the next versions are measured against. Read this before quoting a number. Results are sensitive to CPU, scheduler, compiler and runner. The V1 to V3 deltas come from one hosted CI runner. They are observations, not universal claims, and the repository's forensic report separates hypotheses from proven causes. The V3 decision was to keep zeroization and security hardening and accept the observed cost, not to weaken secret cleanup to win latency. / versions & roadmap Four lines of work V1, V2 and V3 are engineering version lines, not certifications. A GitHub release here does not mean an audit, a certification, production readiness or publication to a package registry. v1.0.0 · Oct 7, 2026V1The frozen engineering baseline: crypto core, vault, keys, identities, policy, audit log, CLI, server and SDKs. Its Arena result showed NEXUS-Q slower than the fastest implementations, which became the main target.Frozen v2.0.0 · Oct 8, 2026V2Correctness, interoperability, security fuzzing, backend strategy and release gates. The final record claims no performance improvement over V1, and the performance question stayed open.Frozen on nexusqv2 Oct 9, 2026 · PR #45V3Hardened implementation, the reproducible Arena, corrected benchmark sampling and a downloadable evidence archive with a SHA-256 manifest. Integrated into main.Current release Issue #23V4Planned architecture-specific kernels: AVX2 and NEON prototypes behind explicit feature dispatch, with a portable fallback. Optimized paths become the default only after differential tests, test vectors, fuzzing, constant-time review and repeatable same-hardware benchmarks.Planned, not a release / security posture What we claim, and what we do not Cryptographic software earns trust slowly. This is the project's own statement of its current assurance level. Claimed and evidenced Standardized algorithms only, through maintained libraries Secrets zeroized when no longer needed Tamper-evident, HMAC-authenticated audit log Deny-by-default policy engine Security CI gates, SDK CI, benchmark CI and fuzz targets Published threat model and security model Dual license: MIT or Apache-2.0 Not claimed Independent external security audit FIPS validation or Common Criteria certification Formal verification Production readiness Publication to crates.io, PyPI or other registries Hardware isolation from the default software backend Performance leadership Found a vulnerability? Report it privately through GitHub Security Advisories, not a public issue. See SECURITY.md. / quick start Build it and use it You need Rust 1.85 or newer. Linux and Android/Termux are the environments exercised most. 1 · Build # clone and build the workspace git clone https://github.com/lecodev-26/nexus-q cd nexus-q cargo build --workspace --release 2 · Create a vault ./target/release/nexusq vault create ./example.nqv ./target/release/nexusq vault status ./example.nqv ./target/release/nexusq health 3 · Generate a key ./target/release/nexusq key generate ./example.nqv \ --algorithm ed25519 --purpose sign \ --password-file ./password.txt ./target/release/nexusq key list ./example.nqv 4 · Encrypt and decrypt data ./target/release/nexusq data encrypt ./example.nqv \ --key-id <key-id> ./secret.txt ./target/release/nexusq data decrypt ./example.nqv \ ./secret.txt.nqx ./secret.out Prefer --password-file over typing a password on the command line, and never commit that file. The full command list is in the CLI guide. Server setup is in docs/SERVER.md. / contribute How you can help NEXUS-Q is built in the open and is still young. The most useful help right now is scrutiny: more eyes, more hardware and more honest measurements. Some of these need no cryptography background. Run the Arena on your hardwareReproduce the benchmark numbers on your own CPU and share what you find in an issue. Differences between machines are exactly what the V4 work needs to know. Start with arena/README.md. Review the threat modelRead the threat model and the security model, and tell us what is missing or wrong. A gap in the reasoning is worth more than praise. Test on your platformBuild the workspace and run the tests on Linux, Android/Termux or RISC-V, and report anything that fails or behaves differently.