{"slug": "nexus-q-update-v4-native-back-end-is-now-in-main", "title": "Nexus-Q update: V4 native back end is now in main", "summary": "Nexus-Q, a post-quantum cryptographic security engine maintained by lecodev-26, has merged its V4 native back end into the main branch, the project announced. Nexus-Q is a Rust library built on the NIST-standardized lattice algorithms ML-KEM and ML-DSA, paired with X25519 for hybrid key exchange and offering AES-256-GCM or ChaCha20-Poly1305 for data and Ed25519, ML-DSA-65 or SLH-DSA for signatures, organized as a Cargo workspace of five Rust crates plus C, Python, Go, PHP and Ruby bindings. The project states it does not claim every dependency has been independently audited, and that hardware isolation is only claimed when a provider for TPM, HSM, Secure Element or RISC-V is implemented and tested, which the default software backend does not provide.", "body_md": "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.\n\n**Built for** developers and teams who embed cryptography in applications and servers that must protect secrets for the long term.\n\nMaintained by [lecodev-26](https://github.com/lecodev-26) · [contributors](https://github.com/lecodev-26/nexus-q/graphs/contributors)\n\nA 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.\n\nAuthenticated encryption of files and streams, with envelope encryption (format F-02) so payloads are protected under a key that is itself protected.\n\nThe full key lifecycle: generation, rotation, revocation and destruction, stored in an encrypted vault (format F-01) with atomic writes.\n\nDigital signatures, signature verification, identity rotation and revocation, and signed verifiable credentials.\n\nLarge 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.\n\n**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.\n\nEvery 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.\n\nA password goes through Argon2id to unlock the encrypted vault. The vault holds keys at rest and is written atomically.\n\nGenerate, rotate, revoke and destroy keys. Secrets are zeroized in memory when they are no longer needed.\n\nHybrid ML-KEM + X25519 for key exchange, AES-256-GCM or ChaCha20-Poly1305 for data, Ed25519, ML-DSA-65 or SLH-DSA for signatures.\n\nA deny-by-default policy engine decides which actions are allowed before they happen.\n\nAn HMAC-authenticated audit log with rollback anchoring makes tampering and truncation detectable.\n\nThe core is a Rust library. The CLI, the server and the SDKs are thin layers on top and contain no cryptography of their own.\n\nProvider 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.\n\nThe threat model and the cryptographic rules were written before the code, and they are part of the repository.\n\nA Cargo workspace of five Rust crates, plus bindings for other languages and a reproducible benchmark arena.\n\n| Component | What it is | \n|---|---|\n| nexusq-core | The library. All cryptography, vault, key management, identity, policy, storage and hardware abstraction live here. | \n| nexusq-cli | The `nexusq` binary: vault, key, data, sign, identity, credential and audit commands. A thin wrapper over the library. | \n| nexusq-server | The `nexusq-server` binary and authenticated HTTP service, with health, readiness and Prometheus-style metrics endpoints. | \n| nexusq-c · nexusq-py | The C SDK and the Python binding, built on the core library. | \n| bindings/go · php · ruby | Language bindings covered by a dedicated SDK CI workflow. | \n| arena/ | The PQC Benchmark Arena: pinned external implementations, a normalized JSONL protocol and retained CI artifacts. | \n| fuzz/ · artifact-archive/ | Fuzz targets, and the archived V1/V2/V3 evidence with SHA-256 manifests. | \n\nLinux x86_64 and aarch64, Android/Termux aarch64, and RISC-V (riscv64gc) with a verified build.\n\nRust 1.85 or newer (edition 2024) and Git. SDK toolchains are only needed for the binding you build.\n\nEncrypted vault, envelope format, backup bundles and a storage database, all with documented formats.\n\nRequest IDs, aggregate metrics, health and readiness probes. Secrets are kept out of logs.\n\nThe 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.\n\n| Family | Purpose | Implemented | \n|---|---|---|\n| Randomness | Entropy for keys, nonces and salts | OS CSPRNG, plus 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 and non-repudiation | Ed25519, ML-DSA-65, SLH-DSA-SHAKE-128f | \n\nPlanned algorithms are never described as available until they are implemented and tested. The reference document is [docs/CRYPTOGRAPHY.md](https://github.com/lecodev-26/nexus-q/blob/main/docs/CRYPTOGRAPHY.md).\n\nNEXUS-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.\n\nV1, 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.\n\nThe 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.\n\nFrozen\nCorrectness, interoperability, security fuzzing, backend strategy and release gates. The final record claims no performance improvement over V1, and the performance question stayed open.\n\nFrozen on nexusqv2\nHardened implementation, reproducible Arena, corrected benchmark sampling and retained evidence archive with SHA-256 manifest.\n\nEngineering release\nExperimental native backend integrated into main; the measured backend passed the 1.5× median-and-p95 gate. Production cryptographic paths in nexusq-core, CLI and SDKs are not wired to this backend yet.\n\nEngineering snapshot · not production-ready\nCryptographic software earns trust slowly. This is the project's own statement of its current assurance level.\n\nFound a vulnerability? Report it privately through GitHub Security Advisories, not a public issue. See [SECURITY.md](https://github.com/lecodev-26/nexus-q/blob/main/SECURITY.md).\n\nYou need Rust 1.85 or newer. Linux and Android/Termux are the environments exercised most.\n\n```\n# clone and build the workspace\ngit clone https://github.com/lecodev-26/nexus-q\ncd nexus-q\ncargo build --workspace --release\n./target/release/nexusq vault create ./example.nqv\n./target/release/nexusq vault status ./example.nqv\n./target/release/nexusq health\n./target/release/nexusq key generate ./example.nqv \\\n  --algorithm ed25519 --purpose sign \\\n  --password-file ./password.txt\n./target/release/nexusq key list ./example.nqv\n./target/release/nexusq data encrypt ./example.nqv \\\n  --key-id <key-id> ./secret.txt\n./target/release/nexusq data decrypt ./example.nqv \\\n  ./secret.txt.nqx ./secret.out\n```\n\nPrefer `--password-file` over typing a password on the command line, and never commit that file. The full command list is in the [CLI guide](https://github.com/lecodev-26/nexus-q/blob/main/docs/user/CLI.md). Server setup is in [docs/SERVER.md](https://github.com/lecodev-26/nexus-q/blob/main/docs/SERVER.md).\n\nNEXUS-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.\n\nReproduce the benchmark numbers on your own CPU and share what you find in an issue. Differences between machines affect reproducibility; treat local results as observations, not official gate evidence. Start with [arena/README.md](https://github.com/lecodev-26/nexus-q/blob/main/arena/README.md).\n\nRead the [threat model](https://github.com/lecodev-26/nexus-q/blob/main/docs/THREAT_MODEL.md) and the [security model](https://github.com/lecodev-26/nexus-q/blob/main/docs/SECURITY_MODEL.md), and tell us what is missing or wrong. A gap in the reasoning is worth more than praise.\n\nBuild the workspace and run the tests on Linux, Android/Termux or RISC-V, and report anything that fails or behaves differently.\n\nThe native backend is experimental and is not yet connected to the production cryptographic paths in nexusq-core, CLI or SDKs. Production integration and end-to-end validation remain future engineering work.\n\nFound a vulnerability? Please report it privately through GitHub Security Advisories, not in a public issue. See [SECURITY.md](https://github.com/lecodev-26/nexus-q/blob/main/SECURITY.md).\n\nEverything below lives in the repository. Start with the user guide, then go as deep as you need.\n\nThe 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.\n\nNo 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.\n\nV1 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 includes an experimental native backend. It has passed the measured-backend 1.5× median-and-p95 gate, but it is not wired into production cryptographic paths and this result is not an end-to-end application benchmark.\n\nA 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.\n\nThe 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.\n\nYou can choose either the MIT license or the Apache License 2.0, the same dual license used by much of the Rust ecosystem.\n\nRead the threat model, run the Arena yourself, review the code, and open an issue or a pull request. V4 native-backend work is an engineering snapshot; production-path integration is not yet complete. Security reports go through GitHub Security Advisories.", "url": "https://wpnews.pro/news/nexus-q-update-v4-native-back-end-is-now-in-main", "canonical_source": "https://nexus-q.link/", "published_at": "2026-10-17 13:44:48+00:00", "updated_at": "2026-10-17 14:03:06.235998+00:00", "lang": "en", "topics": ["artificial-intelligence"], "entities": ["Nexus-Q", "lecodev-26", "ML-KEM", "ML-DSA", "X25519", "Rust", "NIST"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/nexus-q-update-v4-native-back-end-is-now-in-main", "markdown": "https://wpnews.pro/news/nexus-q-update-v4-native-back-end-is-now-in-main.md", "text": "https://wpnews.pro/news/nexus-q-update-v4-native-back-end-is-now-in-main.txt", "jsonld": "https://wpnews.pro/news/nexus-q-update-v4-native-back-end-is-now-in-main.jsonld"}}