Skip to content

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

Latest
Latest

Choose a tag to compare

View all tags
@github-actions github-actions released this 22 Oct 01:26
v4.1.1
a546434

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.

Assets 15
Loading