V3 engineering release · Oct 9, 2026 · no independent audit implied
Post-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 workspace
5SDK languages: C, Python, Go, PHP, Ruby
8implementations in the PQC Benchmark Arena
57normalized 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.
Data
Authenticated encryption of files and streams, with envelope encryption (format F-02) so payloads are protected under a key that is itself protected.
Keys
The full key lifecycle: generation, rotation, revocation and destruction, stored in an encrypted vault (format F-01) with atomic writes.
Identities
Digital 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 rule
We 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.
01
Unlock the vault
A password goes through Argon2id to unlock the encrypted vault. The vault holds keys at rest and is written atomically.
02
Manage keys
Generate, rotate, revoke and destroy keys. Secrets are zeroized in memory when they are no longer needed.
03
Encrypt or sign
Hybrid ML-KEM + X25519 for key exchange, AES-256-GCM or ChaCha20-Poly1305 for data, Ed25519, ML-DSA-65 or SLH-DSA for signatures.
04
Enforce policy
A deny-by-default policy engine decides which actions are allowed before they happen.
05
Audit everything
An HMAC-authenticated audit log with rollback anchoring makes tampering and truncation detectable.
Library first
The 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 boundary
Provider 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 up
The 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.
| Component | What it is |
|---|---|
| nexusq-core | The library. All cryptography, vault, key management, identity, policy, storage and hardware abstraction live here. |
| nexusq-cli | The nexusq binary: vault, key, data, sign, identity, credential and audit commands. A thin wrapper over the library. |
| nexusq-server | The nexusq-server binary and authenticated HTTP service, with health, readiness and Prometheus-style metrics endpoints. |
| nexusq-c · nexusq-py | The C SDK and the Python binding, built on the core library. |
| bindings/go · php · ruby | Language 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. |
Targets
Linux x86_64 and aarch64, Android/Termux aarch64, and RISC-V (riscv64gc) with a verified build.
Requirements
Rust 1.85 or newer (edition 2024) and Git. SDK toolchains are only needed for the binding you build.
Storage
Encrypted vault, envelope format, backup bundles and a storage database, all with documented formats.
Observability
Request 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.
| Family | Purpose | Implemented |
|---|---|---|
| Randomness | Entropy for keys, nonces and salts | OS CSPRNG, plus 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 and non-repudiation | Ed25519, 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, 2026
V1
The 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, 2026
V2
Correctness, 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 #45
V3
Hardened implementation, the reproducible Arena, corrected benchmark sampling and a downloadable evidence archive with a SHA-256 manifest. Integrated into main.
Current release
Issue #23
V4
Planned 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 --release2 · 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 hardware
Reproduce 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 model
Read 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 platform
Build the workspace and run the tests on Linux, Android/Termux or RISC-V, and report anything that fails or behaves differently.
Join the V4 work
Assembly-level ML-KEM and ML-DSA kernels (AVX2, NEON) are tracked in Issue #23. Differential tests, test vectors, fuzzing and a constant-time review come before anything becomes a default.
Found a vulnerability? Please report it privately through GitHub Security Advisories, not in a public issue. See SECURITY.md.
/ documentation
Where to read next
Everything below lives in the repository. Start with the user guide, then go as deep as you need.
/ faq
Questions people ask
Is NEXUS-Q ready for production?
The project does not claim production readiness. It is an engineering project with strong CI gates, but there has been no independent audit or certification. Evaluate it, review it, and treat it accordingly.
Has it been audited?
No independent external audit has been completed, and none is implied by a GitHub release. The project states it will link a public evidence package from the repository if one exists.
Why is it slower than AWS-LC and others?
V1 was built to be correct and secure first. Its Arena run measured it roughly 2 to 4.5 times slower than the fastest implementations. V3 keeps zeroization and hardening and accepts the cost. V4 plans optimized AVX2 and NEON kernels, enabled by default only after a strict validation checklist.
Why combine ML-KEM with X25519?
A hybrid keeps the key exchange protected as long as at least one of the two schemes holds up. That is the usual reasoning for hybrids while post-quantum algorithms are still young in deployment.
Can I use it from Python, Go, C, PHP or Ruby?
The repository includes a C SDK, a Python binding and Go, PHP and Ruby bindings, covered by a dedicated SDK CI. They are not published to package registries, so you build them from source. See the SDK guide.
What license is it under?
You can choose either the MIT license or the Apache License 2.0, the same dual license used by much of the Rust ecosystem.
How can I help?
Read the threat model, run the Arena yourself, review the code, and open an issue or a pull request. Performance work for V4 is tracked in Issue #23. Security reports go through GitHub Security Advisories.