NEXUS-Q v4.1.1 — Final Release | PQC, PKI, SDKs & Runtime Hardening

NEXUS-Q v4.1.1 — Final Release

NEXUS-Q v4.1.1 is the consolidated release of the 4.1.1 development cycle, bringing together post-quantum cryptography integration, expanded PKI capabilities, hardware-backed signing integration, high-availability features, cross-language SDK improvements, runtime distribution, and release-pipeline hardening.

Built around a Rust cryptographic core and a shared C ABI, NEXUS-Q provides a common foundation for applications that need cryptographic services across multiple programming languages.

This release consolidates the work integrated into the repository for version 4.1.1. It establishes the versioned baseline for technical evaluation, integration, interoperability testing, and continued security review.

Highlights

Post-quantum cryptography and PKI

• PQC X.509 certificate issuance: Adds certificate-issuer functionality designed around post-quantum signing capabilities.
• OCSP and certificate revocation: Adds an OCSP responder and certificate revocation list (CRL) publication functionality.
• Certificate enrollment: Integrates ACME, EST, and CMPv2 enrollment workflows.
• ML-DSA hardware integration: Adds PKCS#11-based ML-DSA signing integration and support for M-of-N signing ceremonies.
• Post-quantum timestamping: Adds RFC 3161 timestamp-token functionality using ML-DSA.
• High availability and recovery: Adds tenant-scoped CA/OCSP replication and recovery capabilities.
• Administrative security: Expands role-based access control (RBAC), encrypted backup functionality, and audit logging.

These capabilities extend the project beyond its cryptographic core into certificate lifecycle management, signing infrastructure, administrative operations, and deployment-oriented security workflows.

Rust core and cryptographic backend

• Consolidates the Rust workspace and associated packages at version 4.1.1.
• Continues integration of ML-KEM and ML-DSA capabilities through maintained cryptographic implementations.
• Preserves RustCrypto as the default provider for ordinary production call paths.
• Retains the native ML-KEM/ML-DSA backend behind an explicit opt-in feature.
• Includes native-backend compatibility, differential-testing, error-handling, and kernel-validation work.
• Maintains a clear boundary between the default provider and experimental native implementations.

Important: The native backend remains experimental and is not enabled by default in the CLI, server, or SDKs.

Multi-language SDKs and runtime distribution

The 4.1.1 codebase consolidates work across the Rust packages and language bindings, including:

• Rust libraries, CLI, server, and C SDK.
• Python bindings using PyO3.
• C#/.NET bindings using P/Invoke.
• TypeScript/Node.js bindings.
• Java and Kotlin bindings using JNA.
• Swift bindings.
• Go bindings.
• Ruby and PHP FFI bindings.
• Dart bindings.

The runtime and SDK integration work includes:

• Version-matched native runtime assets.
• Platform-aware runtime selection.
• SHA-256 checksum verification for downloaded runtime binaries.
• Versioned runtime caches.
• Improved first-use runtime resolution and loading diagnostics.
• SDK packaging and clean-consumer validation.
• NuGet packaging with runtime assets for the supported .NET runtime identifiers.

The exact availability and platform requirements vary by SDK. Consult the relevant binding documentation before selecting a deployment target.

Testing, correctness, and engineering quality

The 4.1.1 development cycle includes work on:

• Rust formatting, compilation, Clippy, tests, and documentation checks.
• ML-KEM upstream vectors, NIST/ACVP-related checks, and negative-input coverage.
• Native-kernel differential testing and unsafe-code boundary checks.
• SDK build, smoke-test, packaging, and runtime-loading validation.
• Dependency-audit handling and lockfile synchronization.
• Benchmark result schemas, metadata validation, and comparative performance diagnostics.
• CI workflow maintenance and release-pipeline reliability.

These checks provide engineering evidence for the tested code and configurations. Passing automated checks does not establish the absence of vulnerabilities or replace an independent cryptographic audit.

Benchmarking and performance evaluation

NEXUS-Q includes a reproducible PQC Benchmark Arena and comparative evaluation infrastructure for post-quantum cryptographic operations.

The project records benchmark metadata and measurements to support analysis of latency, variability, and implementation trade-offs. Benchmark results must be interpreted in the context of the tested hardware, compiler, configuration, workload, and reference implementation.

The native backend's experimental status remains unchanged. Benchmark results should not be interpreted as proof of universal performance superiority or as end-to-end application performance guarantees.

Distribution

Version: 4.1.1

Source repository:
https://github.com/lecodev-26/nexus-q

GitHub release:
https://github.com/lecodev-26/nexus-q/releases/tag/v4.1.1

NuGet installation:

dotnet add package Nexusq --version 4.1.1

For Rust and other language ecosystems, use the package coordinates and installation instructions published for the specific SDK. Do not assume that every registry, package, or platform has identical publication status or runtime requirements.

Security status and limitations

NEXUS-Q is an actively developed cryptographic software project. Version 4.1.1 consolidates implementation, integration, testing, and distribution work; it does not represent a claim of independently certified cryptographic security.

• Independent external audit: Not claimed as completed.
• FIPS 140-3 validation: Not claimed.
• Formal verification: Not claimed.
• Production readiness: Must be assessed against the intended threat model, deployment, and operational requirements.
• Native ML-KEM/ML-DSA backend: Experimental and opt-in.
• Default cryptographic provider: RustCrypto for the normal production call paths.
• Hardware isolation: Must not be inferred from an abstraction or SDK integration alone; it depends on a concrete provider and its validated deployment.

Automated CI, benchmark gates, dependency checks, and interoperability tests are important engineering controls, but none individually or collectively substitutes for an independent cryptographic security assessment.

Teams evaluating NEXUS-Q should review the threat model, security documentation, supported configurations, dependency status, and runtime requirements before integrating it into security-sensitive systems.

Release scope

NEXUS-Q v4.1.1 consolidates the changes delivered for this version across cryptographic functionality, PKI, signing integrations, availability and recovery, SDKs, runtime loading, testing, and release engineering.

This is the final release designation for version 4.1.1. It does not imply that the project will receive no future releases or that outstanding security-review work is complete.

Acknowledgements

Thank you to everyone who contributed implementation work, integration fixes, tests, benchmarks, packaging improvements, documentation, and review throughout the 4.1.1 development cycle.

NEXUS-Q v4.1.1 — Final Release. One versioned baseline across the core, PKI capabilities, SDK ecosystem, and runtime distribution, with security limitations stated explicitly.

NEXUS-Q v4.1.0

NEXUS-Q v4.1.0 Stable Line Release

Release identity

• Version: 4.1.0
• Git tag: v4.1.0
• Release branch: main (after PR #55 is merged)
• Release type: stable line release of the V4 work, ready for the final independent audit
• Public GitHub release: published by the tag-gated v4-release.yml path after the full release gate passes

The v4.1.0 release is produced from main after the PR #55 review gates are
green and the two four-hour fuzz soaks have been executed and confirmed green
on the exact merged SHA. The release gate re-runs correctness, security-sensitive
regression, build and packaging checks from the final version.

What this release contains

• The V3 hardened implementation (zeroization, vault/envelope formats, hybrid
  KEM and ML-DSA paths) as previously released on the engineering lines.
• The native backend wired into nexusq-core behind the explicitly opt-in
  native-backend feature: ML-KEM-768/1024 key generation, encapsulation and
  decapsulation, hybrid (X-Wing) encapsulation, and ML-DSA-65 signing and
  verification. RustCrypto remains the default everywhere; the feature is not
  enabled by default in the CLI, the server or any SDK.
• Full error propagation on the native paths (no unjustified panics), identical
  invalid-input verdicts across configurations (including constant-time
  low-order X25519 rejection), and the measured production-path benchmark
  evidence within the unchanged 1.5× median-and-p95 gate.

Final acceptance contract

The release is eligible for publication only when:

1. Every NEXUS-Q workspace package resolves to 4.1.0.
2. Formatting, locked checks, Clippy with -D warnings, debug tests and release
   tests pass.
3. C, Python, CLI and server smoke tests pass.
4. Ubuntu, macOS and Windows release builds pass.
5. The deployment archive is byte-for-byte reproducible when packaged twice
   from the same runner/build output.
6. SHA-256 checksums, a CycloneDX 1.5 SBOM and machine-readable provenance
   are emitted as release evidence.
7. The public v4.1.0 tag path generates a GitHub build-provenance attestation
   for the release archive.
8. The GitHub Release is created only after the complete gate is green.

Pre-tag requirements (before cutting v4.1.0)

1. PR #55 merged into main.
2. The two four-hour fuzz soaks (vault parser, envelope parser) executed and
   confirmed green on the exact merged SHA.
3. Post-merge main CI green.

Publication boundary

This phase publishes the GitHub source/tag/release artifact. It does not
automatically publish crates.io, PyPI or other SDK registries. Those registries
remain separate release operations with their own package metadata, credentials,
compatibility checks, provenance and publication gates.

Security and audit status

• The native backend remains experimental and opt-in; this release does not
  enable it by default anywhere.
• No FIPS 140-3 validation and no pairwise consistency test (PCT) is claimed.
• The Phase 21 independent external audit remains open; this release is prepared
  so that audit can proceed against a stable, versioned line.

NEXUS-Q V4 — Engineering Snapshot (Experimental Backend)

NEXUS-Q V4 — Engineering Snapshot

This release records the NEXUS-Q V4 native-backend engineering milestone. The tag v4-engineering-2026-10-16 pins the V4 merge commit (1c03968e9b8d5578020e571e2f25edc5a7165607). Repository status and user-facing documentation were subsequently aligned on main in commit 6d1336cc0cba9b84cac72af7236addf0a451085a.

Scope and status

• The native backend remains experimental.
• The backend is not yet wired into nexusq-core, CLI, or SDK production cryptographic paths.
• The isolated native-backend performance gate passed at the required 1.5× median-and-p95 threshold.
• Post-merge main CI, SDK checks, benchmark workflows, security regression checks, and the configured four-hour fuzz jobs completed successfully. Jobs marked skipped are not counted as passing evidence.
• This is an engineering reference release, not a stable production release. It does not claim NEXUS-Q v1.0 completion or an independent cryptographic audit.

What comes next

Production-path wiring is being developed separately in PR #55, which remains a draft. The native backend must remain opt-in until correctness, security, portability, API/SDK integration, and production-path performance are verified.

Phases 18–22 (observability, deployment, user documentation, final audit, and the NEXUS-Q v1.0 release candidate) remain required before stable package publication. This engineering release does not authorize stable crates.io/PyPI/SDK publication, enabling the native backend by default, or merging PR #55.

NEXUS-Q V3 — Validated Engineering Release (2026-10-09)

NEXUS-Q V3 — validated engineering release

Status: Validated repository engineering snapshot. This is not a claim of independent security audit, certification, or production readiness, and it does not publish packages to registries.

Included

• Consolidated V3 implementation integrated from nexusqv3 by PR #45.
• Reproducible PQC Benchmark Arena, normalized JSONL measurements, environment metadata, and improved per-operation sample capture.
• LTO/codegen/profile and dependency-source diagnostics; corrected benchmark/profile reports.
• Preserved research and workflow artifacts with SHA-256 manifest at artifact-archive/SHA256SUMS-2026-10-09.txt.
• Updated README, benchmark documentation, changelog, and V3/V4 roadmap.

CI evidence — all successful on commit fbd3fbe1d4fe38d52f58a47e11096fb4ab5bee45

• Security and Release Gates: success, including secret scanning, formatting, Clippy, workspace tests, cargo audit, cargo deny, dependency metadata/SBOM input, fuzz harness build, and 4-hour vault and envelope parser fuzz soaks.
• Security Regression and Fuzzing: success, including security regression, secret scanning, fuzz target build, and 4-hour vault, envelope, and backup-import fuzz soaks.
• SDK CI: success across C prerequisite, Dart/Flutter, Swift, Java/Kotlin UniFFI, TypeScript/WebAssembly, and C#/.NET toolchains.
• V3 Incremental CI: success.
• PQC Benchmark Arena: success.
• Local cargo fmt --all -- --check and git diff --check: passed. All entries in artifact-archive/SHA256SUMS-2026-10-09.txt verified successfully.

Performance evidence

In the recorded 10-round paired hosted-runner comparison, V3 median latency vs V1 was +2.70% to +6.33% across the six ML-KEM operations; ML-DSA-65 keygen +6.82%, conventional verify +6.40%, and signing -0.76%. Per-round ranges and caveats are documented in BENCHMARKS.md and the forensic report. These are observations from one hosted runner, not universal performance guarantees. The evidence does not prove SHA3/SHAKE zeroization caused the ML-KEM deltas. V3 retains zeroization and accepts the observed security/performance tradeoff.

Versioning / packages

This engineering snapshot uses tag v3-engineering-2026-10-09. Cargo workspace package versions remain 2.0.0; no crates.io, PyPI, or other SDK registry packages are published by this release.

Downloadable release evidence

• nexusq-v3-evidence-2026-10-09.zip — retained benchmark ZIPs, benchmark documentation, artifact archive index, checksum manifest, and V1/V3 forensic report.
• nexusq-v3-evidence-2026-10-09.zip.sha256 — SHA-256 for the downloadable evidence bundle.

The evidence archive is not a distributable executable binary. No V3 executable was attached because the retained CI artifacts do not include a verified V3 release binary. The release tag remains pinned to the validated source commit above; final post-release main validation is tracked separately in Actions.

Latest finalization commit: 8a7e35f8537af9aba8e33e99f33a51856ae0203d. This commit updates benchmark workflow triggers so the benchmark and Arena badges can report the main branch, refreshes README validation wording, and tracks the downloadable evidence bundle. The finalization commit has a new CI/fuzz cycle in progress; do not describe that cycle as passed until the runs finish successfully.

NEXUS-Q v2.0.0

NEXUS-Q v2.0.0 Final Release

Release identity

• Version: 2.0.0
• Git tag: v2.0.0
• Release branch: nexusqv2
• Release type: final engineering release
• Public GitHub release: published by the protected v2.0.0 tag path after final gates pass

The v2.0.0 release is produced from the merged nexusqv2 line after the V2-10
performance gate and V2-11 release-candidate gate. The final release gate
re-runs correctness, security-sensitive regression, build and packaging checks
from the final version. V2 is intentionally frozen without claiming a performance
win over V1; the retained Arena comparison is the baseline for V3.

Final acceptance contract

The release is eligible for publication only when:

1. Every NEXUS-Q workspace package resolves to 2.0.0.
2. Cargo.lock is locked and contains no 2.0.0-rc.1 package entries.
3. Formatting, locked checks, Clippy with -D warnings, debug tests and release
   tests pass.
4. C, Python, CLI and server smoke tests pass.
5. Ubuntu, macOS and Windows release builds pass.
6. The deployment archive is byte-for-byte reproducible when packaged twice
   from the same runner/build output.
7. SHA-256 checksums, a CycloneDX 1.5 SBOM and machine-readable provenance
   are emitted as release evidence.
8. The public v2.0.0 tag path generates a GitHub build-provenance attestation
   for the release archive.
9. The GitHub Release is created only after the complete gate is green.

Publication boundary

This phase publishes the GitHub source/tag/release artifact. It does not
automatically publish crates.io, PyPI or other SDK registries. Those registries
remain separate release operations with their own package metadata, credentials,
compatibility checks, provenance and publication gates.

A successful GitHub release therefore must not be interpreted as proof that
every downstream registry or commercial-readiness requirement is complete.

Verification

Download the release archive and its checksum from the GitHub Release, then:

sha256sum -c nexusq-v2.0.0-<TARGET>.tar.gz.sha256

After extraction:

cd nexusq-v2.0.0-<TARGET>
sha256sum -c SHA256SUMS

GitHub's artifact-attestation UI/API can be used to verify the build provenance
for the published archive.

Security and evidence boundary

The release gate preserves the existing NEXUS-Q security model and does not
change cryptographic parameters, key-management semantics, zeroization policy,
audit-chain semantics or backend security boundaries.

An external security audit, formal certification, legal/compliance review,
commercial support/SLA, customer validation and package-registry publication
remain distinct claims and must not be inferred from the GitHub release alone.

NEXUS-Q v1.0 — Frozen Engineering Baseline

NEXUS-Q v1.0 — Frozen Engineering Baseline

NEXUS-Q v1.0 is the project's completed and frozen engineering baseline as of 2026-10-07. It is preserved as the reference point for the v2 optimization line.

Included

• Core cryptography, vault, envelope, identity, policy, storage and CLI implementation.
• Observability and deployment documentation.
• User documentation and troubleshooting guidance.
• SDK/binding baseline and CI validation.
• Security CI including secret scanning, dependency/security gates, fuzz harness builds and extended parser fuzzing.
• PQC Benchmark Arena with pinned external implementations and normalized benchmark evidence.
• Deterministic release packaging and metadata.
• Correct Cargo repository metadata for the public NEXUS-Q repository.

Explicit non-claims

• No independent external cryptographic/security audit has been performed.
• No public registry/package publication is made by this release. crates.io, PyPI, npm and other package registries remain intentionally deferred.
• v1 is not presented as a performance leader; the benchmark baseline records material gaps versus faster mature implementations on measured PQC operations.
• This release does not claim FIPS validation, Common Criteria certification, formal verification, or other production certification.

Licensing

NEXUS-Q is dual-licensed under the MIT License or Apache License 2.0, at the user's option. See LICENSE-MIT and LICENSE-APACHE.

V2 hand-off

The nexusqv2 development line continues from this frozen baseline. V2 focuses on benchmark-driven performance optimization and subsequent release gates.

This GitHub release is a historical engineering baseline, not the final commercial NEXUS-Q release.