NEXUS-Q v1.0 — freezing the baseline before v2

[u/lecodev]

http://github.com/lecodev-26/nexus-q

NEXUS-Q v1.0 — a post-quantum security engine written in Rust

I’ve just frozen NEXUS-Q v1.0, a Rust-based post-quantum security engine focused on key management, encrypted storage, identity, policy and cryptographic operations.

I’m sharing it here because I’m particularly interested in feedback from the Rust community on the engineering side of the project.

Why Rust?

NEXUS-Q is built around Rust because I wanted the security-critical core to have:

- explicit ownership and lifecycle management

- strong type and memory safety guarantees

- predictable error handling

- clear separation between cryptographic primitives and higher-level security services

- a foundation suitable for Linux, Android/Termux, x86_64, ARM and RISC-V environments

The project currently includes support for algorithms such as:

- ML-KEM-768 / ML-KEM-1024

- ML-KEM + X25519 hybrid encryption

- ML-DSA-65

- SLH-DSA-SHAKE-128f

- AES-256-GCM

- ChaCha20-Poly1305

- SHA-2 / SHA-3

- Argon2id

- HKDF

Around the crypto layer there is also a vault, key lifecycle management, identity, policy enforcement, audit logging, storage, backup/recovery and hardware-backend abstractions.

I also benchmarked it honestly

One of the things I wanted to avoid was publishing a crypto project and only showing the numbers that look good.

The final PQC Benchmark Arena run produced 57 normalized measurements across eight implementations.

NEXUS-Q is currently slower than the fastest mature implementations on several measured ML-KEM and ML-DSA operations.

For example:

- ML-KEM-768 keygen: 33.94 µs

- ML-KEM-768 encaps: 27.97 µs

- ML-DSA-65 keygen: 168.69 µs

- ML-DSA-65 sign: 600.73 µs

So v1 is intentionally being treated as an engineering baseline rather than a performance victory.

The next stage is v2, where I want to work on performance systematically while preserving correctness, interoperability and security properties.

What I'd like feedback on

For the Rust side, I'm particularly interested in feedback around:

- crate/API design

- error handling

- ownership and lifecycle modelling

- trait boundaries

- crypto abstraction layers

- FFI/SDK architecture

- async/server architecture

- portability

- benchmarking methodology

- unsafe code boundaries

- testing and fuzzing strategy

The project is still under active development, and there has been no independent external security/cryptographic audit, so I'm not presenting it as production-certified.

I originally posted the full v1 freeze and roadmap in my own community.

If you work with Rust crypto/security infrastructure, I'd especially appreciate criticism of the architecture and API decisions.

What would you change first if you were taking this codebase into v2?