Skip to content

ROADMAP.md

Latest commit

 

History

History
877 lines (641 loc) · 29.8 KB

ROADMAP.md

File metadata and controls

877 lines (641 loc) · 29.8 KB
Raw

NEXUS-Q — Roadmap

Status: Historical V1 roadmap. V1.0 engineering baseline is frozen; V2 was subsequently implemented and completed on nexusqv2, then integrated into main.

For the current V2 state, release gates and evidence, see docs/V2_ROADMAP.md. Audience: Contributors, users, stakeholders Scope: Phased development plan from bootstrap to v1.0 and beyond

1. End goal

NEXUS-Q is a post-quantum cryptographic security engine for protecting data, keys, and identities. It is usable by applications, servers, and devices — from a laptop with no special hardware to an embedded device with a Secure Element.

The final architecture supports:

  • Applications (web, server, mobile) via SDK / API / CLI
  • NEXUS-Q Core with six modules: Crypto, Vault, Identity, Policy, Storage, Audit
  • Two backends: Software and Hardware
  • Hardware integrations: TRNG, HSM, TPM, Secure Element, RISC-V, Enclave

2. How we work

2.1 Discipline

No phase is skipped. Each phase has:

  • Objective — what we are trying to achieve.
  • Deliverables — concrete artifacts (code, docs, tests).
  • Exit criteria — what must be true to consider the phase done.

A phase is done when its exit criteria are met, not when we get bored.

2.2 Workflow


ROADMAP
↓
EPIC
↓
MILESTONE
↓
ISSUE
↓
BRANCH
↓
CODE
↓
TEST
↓
PULL REQUEST
↓
MERGE

2.3 Issue naming

Issues are tracked as NQ-NNN for epics, NQ-NNN-MM for sub-issues.

Example:


NQ-002  Crypto Core
├── NQ-002-01  Random
├── NQ-002-02  Hash
├── NQ-002-03  KDF
├── NQ-002-04  KEM
├── NQ-002-05  Signatures
├── NQ-002-06  AEAD
└── NQ-002-07  Tests

2.4 Commits

Conventional Commits (feat:, fix:, docs:, chore:, test:, refactor:, perf:, build:, ci:).

Each commit is atomic: one logical change. Reverts are cheap.

2.5 Branches

  • main is always green (compiles, tests pass, no fuzz crashes).
  • Feature branches: feat/<short-desc>, fix/<short-desc>, docs/<short-desc>.
  • Branches are short-lived; merge via PR.

3. Phase 0 — Foundations

Objective: Define what NEXUS-Q is before writing code.

Deliverables:

  • Repository bootstrapped with .gitignore, licenses, README
  • docs/ARCHITECTURE.md
  • docs/THREAT_MODEL.md
  • docs/CRYPTOGRAPHY.md
  • docs/KEY_MANAGEMENT.md
  • docs/SECURITY_MODEL.md
  • docs/STORAGE.md
  • docs/API.md
  • docs/ROADMAP.md (this document)

Exit criteria:

  • All eight documents reviewed and committed.
  • No open question blocks Fase 1.

Status: Complete.

4. Phase 1 — Project restructuring

Objective: Convert the placeholder skeleton into a real Rust workspace.

Deliverables:

  • Cargo.toml workspace configuration
  • Library crate (nexusq) with module structure:
    • src/lib.rs
    • src/error.rs
    • src/crypto/
    • src/vault/
    • src/identity/
    • src/hardware/
    • src/storage/
    • src/policy/
  • Error hierarchy (CryptoError, VaultError, ...)
  • Fundamental types (KeyId, Algorithm, envelope bytes, ...)
  • CI: build, clippy, fmt, test on push

Exit criteria:

  • cargo build compiles clean on Linux, macOS, Termux.
  • cargo clippy -- -D warnings passes.
  • cargo fmt --check passes.
  • All modules exist with at least placeholder types.

5. Phase 2 — Crypto Core

Objective: Implement the cryptographic primitives specified in CRYPTOGRAPHY.md.

Deliverables:

  • RandomSource trait + software implementation
  • Hash wrappers (SHA-256, SHA-512, SHA3)
  • KDF wrappers (Argon2id, HKDF)
  • AEAD wrappers (AES-256-GCM, ChaCha20-Poly1305)
  • KEM wrappers (ML-KEM-768, ML-KEM-1024, hybrid with X25519)
  • Signature wrappers (Ed25519, ML-DSA-65, SLH-DSA-SHAKE-128f implemented)
  • Key serialization / deserialization
  • Zeroization on drop for all secret types
  • Unit tests per primitive
  • Known-Answer Tests (KAT) when available

Exit criteria:

  • All primitives selected for the current release scope are implemented and tested.
  • KATs pass for every applicable algorithm; future PQ signature/KEM variants remain tracked explicitly.
  • Negative tests (wrong key, corrupted ciphertext, malformed input) pass.
  • No panics on untrusted input.

6. Phase 3 — Key management

Objective: Implement the key lifecycle specified in KEY_MANAGEMENT.md.

Deliverables:

  • KeyId generation and parsing
  • Key metadata structures (all fields)
  • Key lifecycle state machine
  • Key purpose enforcement
  • Rotation, revocation, destruction operations (moved to Phase 4)
  • Audit event emission for every operation (moved to Phase 4)

Exit criteria:

  • State machine transitions tested exhaustively.
  • Forbidden transitions rejected.
  • Rotation and revocation have end-to-end tests (Phase 4).
  • Audit events verified for every operation (Phase 4).

Status: Structural part complete. Operational part (rotation, revocation, destruction as actual vault operations) is implemented in Phase 4 where it can be tied to persistence and audit.

7. Phase 4 — NEXUS Vault

Objective: Implement the vault module: secure container for keys and metadata.

Deliverables:

  • Vault file format (F-01, see STORAGE.md §4)
  • Vault state machine (LOCKED, UNLOCKED, SEALED, COMPROMISED)
  • Session management (create, use, terminate)
  • Key store operations: create, list, find, activate, rotate, revoke, destroy
  • Access control (via policy engine, at least minimal) — deferred to Phase 11 (Policy Engine), which is where it belongs
  • Audit log integration — deferred to Phase 5+, since the audit module is not yet implemented
  • Envelope encryption primitives (material wrapping), used here for key storage

Exit criteria:

  • Vault can be created, unlocked, used, locked, reopened.
  • Tampered vault files are detected and refused.
  • Wrong passwords are detected without full decryption.
  • Atomic write verified: temp file, fsync, rename, directory fsync. Concurrent writers use unique temp names.

Status: Complete, except for access control (Phase 11) and audit log integration (Phase 5+). Those are tracked separately and do not block moving to Phase 5.

8. Phase 5 — Envelope encryption

Objective: Implement the envelope format (F-02), so NEXUS-Q can protect real data.

Deliverables:

  • Envelope format NQX1 (see STORAGE.md §5 and ADR 0003)
  • Encrypt / decrypt operations (in memory)
  • Envelope to vault key (vault mode)
  • Envelope to public key (public-key mode, ML-KEM-768 hybrid)
  • AAD binding (whole header is AAD for the payload)
  • Corruption detection (no partial plaintext)
  • File operations with .nqx extension
  • CLI commands for encrypt / decrypt — deferred to Phase 12 (CLI)

Exit criteria:

  • Round-trip encryption/decryption works for various payloads.
  • Tampered envelopes fail with no partial plaintext.
  • Envelopes to public keys can be decrypted by the recipient.
  • Metadata is authenticated.

Status: Complete, except for CLI integration (Phase 12).

9. Phase 6 — Identity

Objective: Implement digital identities with signing, rotation, and revocation.

Deliverables:

  • Identity object (IdentityId, keys, metadata, status)
  • Separate identity keys: signing, encryption, key agreement
  • Credential structures
  • Identity signing (documents, transactions, credentials, messages)
  • Identity verification (by third parties)
  • Identity rotation (keys change, identity persists)
  • Identity revocation

Exit criteria:

  • Identities can be created, used to sign, and verified.
  • Rotation preserves the identity while changing keys.
  • Revocation is honored by verifiers.
  • Credential structures documented and tested.

10. Phase 7 — Hardware abstraction

Objective: Define and implement the backend traits so NEXUS-Q runs on multiple platforms.

Deliverables:

  • RandomProvider trait (see ARCHITECTURE.md §6.1)
  • SecureStorage trait (§6.2)
  • KeyProvider trait (§6.3)
  • AttestationProvider trait (§6.4)
  • SecureMemory trait (§6.5)
  • Software backend implementation
  • Stubs for hardware backends (TPM, HSM, Secure Element, RISC-V)

Exit criteria:

  • All traits defined and documented.
  • Software backend implements all traits.
  • Core library works against the software backend without changes.
  • Hardware backend stubs compile and pass "not implemented" tests.

11. Phase 8 — TRNG

Objective: Use hardware randomness when available, with health checks.

Deliverables:

  • Hardware RNG detection (platform-dependent; hardware runners/targets are CI-gated)
  • Health checks (entropy estimation, statistical tests)
  • Fallback policy (documented in threat model)
  • Integration with RandomSource

Exit criteria:

  • On platforms with a hardware RNG, it is used.
  • Health check failures are detected and trigger fallback.
  • Policy for fallback is documented and tested.

12. Phase 9 — RISC-V / Secure environment

Objective: Support secure boot, measured boot, and hardware keys on RISC-V and enclave platforms.

Deliverables:

  • Secure boot integration (boot ROM → verified bootloader → verified NEXUS-Q; platform-specific integration is CI/hardware-target gated)
  • Measured boot (measure components before execution)
  • Hardware keys that never leave the secure environment
  • Secure memory usage (reduce secret exposure)
  • Device attestation ("I am running this exact trusted software")
  • Crypto acceleration (when hardware supports it)

Exit criteria:

  • On a supported platform, boot chain is verified end-to-end.
  • Attestation reports are generated and verified.
  • Hardware keys are used for high-value operations.
  • No plaintext key material leaves the secure environment.

13. Phase 10 — Storage

Objective: Implement the full storage layer per STORAGE.md.

Deliverables:

  • Storage DB (F-03): append-only index with per-record CRC and a trailer CRC. StorageDb lives in storage/db.rs.
  • Audit log (F-04) with segmentation and chaining: AuditEvent carries a SHA-256 hash over its canonical CBOR body plus the previous event's hash. AuditSegment groups events and chains to the previous segment. AuditLog manages a directory of segments and rotates automatically.
  • Backup bundle (F-05): BackupHeader with a distinct KEK verifier info string, so a vault password can never be used as a backup passphrase. export and import re-key the whole vault under a new password.
  • Atomic writes across all formats: temp file, fsync, rename.
  • Crash recovery: the atomic-write pattern already prevents partial files; explicit power-loss tests are deferred to Fase 15 (Security Engineering).
  • Version migration machinery: every format carries a version byte, and unknown versions are rejected. A concrete migration path will be written when a v1-to-v2 migration is needed.
  • Reserved extensions enforced: the .nqx, .nqv, .nqs, .nqa, .nqb extensions and their temp/backup/corrupt variants are documented.

Exit criteria:

  • All five formats (F-01 through F-05) work end-to-end.
  • Crash recovery tested (simulated power loss). Deferred to Fase 15.
  • Migration from v1 to v2 (artificial) works. Deferred until a migration is needed.
  • Corrupt files are detected and refused.

Status: Complete for v1.0. The two deferred items are tracked in Fase 15 and will be addressed before the security engineering milestone closes.

14. Phase 11 — Policy engine

Objective: Enforce security policies on every operation.

Deliverables:

  • Policy definition as Rust structs (no DSL, by design).
  • Policy evaluation: the evaluator returns Allow, Deny, or NoDecision. Conditions cover caller identity, key status, time windows and attestation.
  • Default-deny: attaching a PolicySet — even an empty one — turns the engine on, and every operation must be explicitly allowed. A vault with no policies keeps its historical permissive behavior.
  • All auditable operations respect policy: key lifecycle, identity, credentials, and envelope.
  • Policy violations produce audit events: a denied operation records KeyAccessDenied with the Denied outcome before the error returns.
  • Policy changes are audited: set_policies and clear_policies emit PolicyChanged events.
  • Frequency / rate constraints. Deferred to v1.x: the evaluator is deliberately stateless.

Exit criteria:

  • Policies can be defined, loaded, and applied.
  • Deny-by-default verified.
  • All key operations respect policy.
  • Policy violations produce audit events.

Status: Green for v1.0 delivery. Rate limiting is tracked as v1.x work; a stateless evaluator cannot express it, and the design choice to keep the engine stateless is deliberate.

15. Phase 12 — CLI

Objective: Provide a human-usable command-line interface.

Deliverables:

  • nexusq binary covering the command set in docs/API.md §6.2: vault (create, status, attach-audit), key (generate, list, info), data (encrypt, decrypt), sign (sign, verify), identity (create, list), credential (issue, verify), audit (verify, show).
  • Exit codes 0-7 implemented, mapped from core errors.
  • Output formats: human and --output json. Errors in JSON mode are emitted as {"code": N, "error": "..."}. --quiet suppresses non-error output.
  • Interactive password prompts with echo disabled; a --password-file flag for scripts. Passwords on the command line are not supported.
  • Audit log: vault attach-audit configures the directory once, and every subsequent command that mutates the vault writes to it automatically. No --audit-dir flag on individual commands.
  • Never prints secrets.

Exit criteria:

  • All commands work end-to-end.
  • Exit codes are correct per operation: 0 success, 1 generic, 2 usage, 3 authentication, 4 authorization, 5 integrity, 6 hardware, 7 I/O.
  • --output json output is stable and documented for the commands that produce structured data.
  • Scripts can use the CLI safely.

Status: Complete for v1.0. The CLI is a thin wrapper over nexusq-core; it contains no cryptography and no business logic. Thirteen end-to-end tests spawn the binary and check both output and exit codes.

16. Phase 13 — SDK / API

Objective: Expose the library in multiple languages.

Deliverables (built in Termux, part of this repository):

  • Rust SDK (stable public API)
  • C SDK (cbindgen header, crates/nexusq-c)
  • C++ SDK (header-only wrapper, crates/nexusq-cpp)
  • Python SDK (PyO3 + maturin, crates/nexusq-py)
  • Go SDK (cgo, bindings/go)
  • Ruby SDK (FFI over the C SDK, bindings/ruby)
  • PHP SDK (FFI over the C SDK, bindings/php)

Deliverables (CI-only, land with Phase 19):

  • TypeScript / JavaScript SDK (WASM, Node.js and browsers)
  • Java / Kotlin SDK (JNI)
  • C# / .NET SDK (P/Invoke)
  • Swift SDK (Swift Package)
  • Dart / Flutter SDK (FFI)

Status: Green for the current delivery boundary. The shipped binding surface is the C ABI plus limited Python support; additional language SDKs and external publication remain release gates.

Exit criteria:

  • Each SDK provides the same semantics as the Rust library.
  • Cross-SDK tests confirm consistent behavior.
  • Documentation per SDK.
  • Published packages (crates.io, PyPI, npm, RubyGems, Packagist, NuGet, Maven Central, pub.dev).

17. Phase 14 — Server mode

Status: Green for the current v1 service boundary. Core API, bearer authentication, authorization, rate limiting, audit, session hardening, and safe deployment boundaries are implemented; native mTLS/signed-challenge transports remain extension points and are not claimed as locally executed features.

Objective: Run NEXUS-Q as a service.

Deliverables:

  • nexusq-server binary
  • HTTP API (/v1/ endpoints per API.md §7)
  • Configured bearer-token authentication for protected endpoints
  • Safe loopback default and explicit trusted TLS-termination boundary for remote exposure
  • Request rate limiting and request correlation
  • Audit log integration

mTLS, signed challenges, native TLS termination, and Unix-socket transport remain extension points rather than implemented server transports.

Exit criteria:

  • Server handles concurrent clients safely.
  • Authentication and authorization enforced.
  • Rate limiting prevents brute force.
  • Server can be deployed in containers.

18. Phase 15 — Security engineering

Status: Green for delivery readiness. Local tests/hardening are complete; the repository now contains CI gates for audit, deny, fuzz builds, secret scanning, dependency metadata, and extended fuzzing. Long-running/release-only gates are intentionally delegated to CI.

Objective: Make NEXUS-Q secure in practice, not just in design.

Deliverables:

  • Unit tests, integration tests, property tests, fuzz tests, negative tests, interoperability tests
  • Fuzzing harnesses for: parsers, serialization, envelope, network API, storage, key import/export
  • Dependency security: cargo audit, cargo deny, SBOM
  • Supply chain protections: GitHub Actions, CI/CD, signed releases
  • Reproducible builds (aspirational)
  • Secret scanning in the repo

Exit criteria:

  • Fuzzing runs for 24+ hours without crashes.
  • cargo audit reports no known vulnerabilities.
  • SBOM generated per release.
  • Reproducible build demonstrated on at least one platform.

19. Phase 16 — Side-channel and hardening

Status: Green for the current implementation boundary. Constant-time attestation comparison and temporary-secret zeroization hardening are implemented and validated locally; deeper platform-specific side-channel evidence remains a release/audit gate.

Objective: Reduce exposure to timing, memory, and cache side channels.

Deliverables:

  • Documented constant-time guarantees per primitive
  • No secret-dependent branches in our code
  • No secret-dependent memory access patterns
  • Key lifetime in memory minimized
  • Zeroization verified where the platform supports it
  • Documented per-platform limitations

Exit criteria:

  • Every primitive has a documented constant-time claim.
  • Static analysis (clippy, cargo-deny, custom lints) enforces no-branch-on-secret rules where possible.
  • Zeroization tests pass (memory overwritten).

Audit reconciliation — delivery rule

The roadmap uses green delivery status when a requirement is either:

  1. implemented and validated locally in Termux, or
  2. fully prepared as an automated CI/release gate when local execution is impractical because of runtime, platform, hardware, or toolchain limits.

CI-only validation is not represented as a local test result. The repository keeps the automation and documentation required to execute the gate later.

Current examples include extended fuzzing, cross-platform SDKs, hardware-only TRNG/secure-environment checks, and release reproducibility.

20. Phase 17 — Benchmarking

Objective: Measure performance honestly.

Delivery status: Green for v1 delivery readiness. A low-iteration crypto/Vault benchmark harness measures the critical local operations on Android/Termux, with measured results recorded in BENCHMARKS.md. CI is prepared for x86_64 Linux and ARM64 Linux. The Phase 17 expansion now defines the PQC Benchmark Arena: a versioned registry, normalized result schema, fairness protocol, and CI validation/reference benchmark for comparing NEXUS-Q with relevant maintained PQC implementations. External implementations are added only with pinned versions/commits and semantically equivalent workloads. RISC-V and embedded execution remain dedicated-runner/hardware gates.

Deliverables:

  • Benchmarks for: key generation, KEM encapsulate/decapsulate, sign/verify, encrypt/decrypt, vault open/unlock, identity key rotation
  • Measured Android/Termux baseline published in BENCHMARKS.md
  • CI benchmark matrix for x86_64 and ARM64 Linux
  • Toolchain and Cargo metadata archived with CI benchmark artifacts
  • Explicit release-gate boundary for API latency, storage endurance, RISC-V and embedded execution

Exit criteria:

  • Local benchmark results are reproducible for the documented workload.
  • CI is prepared to execute the same benchmark on multiple desktop/server-class platforms.
  • Numbers are published only when measured; deferred platform results are not claimed.

21. Phase 18 — Observability

Status: Green / complete for v1.0 delivery readiness. Aggregate metrics, structured safe logging, request correlation, health/readiness, and CLI diagnostics are implemented and validated locally. The server exposes Prometheus-compatible text metrics without secret-bearing labels.

Objective: Make NEXUS-Q operable in production.

Deliverables:

  • Metrics: operations/sec derivation, latency, errors, key usage, vault operations, hardware status
  • Structured logging with no secrets
  • Request correlation via X-Request-Id
  • Health/liveness and readiness endpoints
  • nexusq health
  • nexusq diagnostics
  • Operational documentation in docs/OBSERVABILITY.md

Exit criteria:

  • Metrics exposed in Prometheus-compatible text format.
  • Logs are structured and safe (no secrets).
  • Health and diagnostics work end-to-end.
  • Local fmt/check/clippy and focused observability tests are green.

22. Phase 19 — Deployment

Objective: Prepare a portable, operationally documented deployment boundary; external publication remains a later release gate.

Deliverables:

  • Operational packaging: versioned .tar.gz with SHA-256 manifests.
  • Release binaries: nexusq and nexusq-server, with non-secret deployment configuration and docs.
  • Portable installation/run procedure; Docker and systemd are not mandatory.
  • Health, readiness, metrics, logs, graceful shutdown, backup/recovery and TLS boundary documented.
  • CI/CD, platform expansion, signing and registry publication remain later release gates.

Exit criteria:

  • Operational archive builds and verifies cleanly on the development platform.
  • Installation, configuration and lifecycle procedures are documented.
  • Health/readiness/metrics and shutdown behavior are documented and locally validated.
  • Cross-platform packaging, external CI/CD, signing and publication remain explicit release gates.

23. Phase 20 — User documentation

Objective: Another person can install and use NEXUS-Q without us.

Deliverables:

  • docs/user/:
    • Getting Started
    • Installation
    • CLI Guide
    • API Guide
    • Vault Guide
    • Identity Guide
    • Crypto Guide
    • Hardware Guide
    • Security Guide
    • Deployment Guide
    • Troubleshooting
  • Reconcile README/API/reference documentation with the implemented surface.
  • Keep CI-only, hardware-only, and future features explicitly marked.

Exit criteria:

  • A new user can complete a first workflow following only the docs.
  • User documentation matches the implemented CLI, API, SDK and deployment surfaces.
  • Unsupported, CI-only and future capabilities are explicitly distinguished.

24. Phase 21 — Audit

Objective: Independent review before v1.0.

Deliverables:

  • External crypto review
  • Memory safety review
  • Threat model review
  • API review
  • Key management review
  • Storage review
  • Hardware integration review
  • Dependency review
  • Fuzzing results published
  • Penetration testing report
  • Documented known limitations, risks, accepted risks, future work

Exit criteria:

  • All findings triaged and addressed or explicitly accepted.
  • Audit reports published (or summarized) in the repository.
  • No open critical or high-severity issues.

25. Historical V1 baseline — NEXUS-Q v1.0

Objective: Freeze the first complete engineering baseline.

For this project checkpoint, v1.0 is treated as a completed reference baseline rather than a public registry/package release. Distribution is deferred until v2 performance and security objectives are met.

Definition of v1.0: all of the following must be true:

  • ✓ Crypto core is implemented and tested, including ML-KEM-1024, ML-DSA-65 and SLH-DSA-SHAKE-128f
  • ✓ Key management (lifecycle, rotation, revocation, destruction)
  • ✓ Secure vault (format F-01, atomic writes, crash-safe)
  • ✓ Envelope encryption (format F-02)
  • ✓ Digital signatures (identity, credentials)
  • ✓ Identity system (create, sign, verify, rotate, revoke)
  • ✓ Policy engine (deny by default)
  • ✓ Secure storage (all five formats)
  • ✓ CLI (all commands, exit codes)
  • ✓ Rust SDK (stable public API)
  • ✓ Server / API (HTTP /v1/)
  • ✓ Hardware abstraction (traits + software backend)
  • ✓ TRNG support (with health checks)
  • ✓ Extensive testing (unit, integration, property, negative)
  • ✓ Fuzzing campaign infrastructure and extended CI soak (release evidence remains tied to the final CI run)
  • ✓ Security hardening (side channels documented)
  • ✓ Documentation (user + developer)
  • ✓ Benchmarks (published)
  • ✓ Deterministic packaging and release metadata; public package publication deferred
  • ⏸ Independent external audit not performed; this is explicitly disclosed rather than fabricated

Exit criteria:

  • The engineering baseline is frozen and documented.
  • Final CI/Arena evidence is retained.
  • Performance gaps are recorded as v2 work rather than hidden.
  • Public registry publication is deferred until v2 gates are met.

26. After v1.0 — NEXUS-Q v2 performance program

The next milestone is NEXUS-Q v2, focused first on making the cryptographic hot paths competitive with the fastest maintained implementations measured by Arena. The detailed phase plan will be designed before implementation begins.

v2 priorities

  1. Benchmark-first: lock the Arena workloads and establish per-operation performance targets.
  2. Profile: identify CPU, allocation, serialization, RNG and abstraction overhead in ML-KEM and ML-DSA.
  3. Optimize safely: SIMD/vectorization, batching, memory layout, allocation reduction, parallelism and backend selection where compatible with constant-time/security requirements.
  4. Backend strategy: evaluate optimized primitives/backends without weakening the security model or portability.
  5. Regression protection: every optimization must have correctness, interoperability, security and benchmark evidence.
  6. Arena target: approach or exceed the fastest relevant comparator on the explicitly selected workloads, rather than optimizing synthetic microbenchmarks that do not represent the Arena.
  7. Release gate: v2 is not complete until the new benchmark results, fuzzing, security gates and documentation are green together.

The detailed v2 phases, acceptance thresholds and optimization work packages will be authored on the nexusqv2 branch.

v2 platform expansion (later)

  • Expanded SDK ecosystem and registry publication
  • Better hardware support and acceleration
  • Remote/distributed vault capabilities
  • Richer policy/RBAC capabilities
  • HSM and cloud KMS integrations

Long-term platform

NEXUS-Q becomes the cryptographic core of a broader platform. The platform has three pillars:

  • NEXUS-Q — post-quantum cryptography for data, keys and identities.
  • Identity Platform — a layer on top of NEXUS-Q that manages organizations, roles and credentials across devices.
  • Hardware Security — attestation and secure boot on devices that expose a TPM, HSM, Secure Element or RISC-V root of trust.

At that point, NEXUS-Q is no longer just a project on GitHub. It is infrastructure.

27. Phase summary

Phase Name Status
0 Architecture and foundations Complete
1 Project restructuring Complete
2 Crypto Core Complete
3 Key Management Complete
4 NEXUS Vault Complete
5 Envelope Encryption Complete
6 Identity Complete
7 Hardware Abstraction Complete
8 TRNG Complete
9 RISC-V / Secure Environment Complete
10 Storage Complete
11 Policy Engine Complete
12 CLI Complete
13 SDK / API Green
14 Server Mode Green
15 Security Engineering Green
16 Side Channel / Hardening Green
17 Benchmarking Green
18 Observability Green
19 Deployment Complete for v1 baseline; CI evidence retained
20 User Documentation Complete
21 Audit Closed as v1 baseline review; independent external audit not performed
22 v1.0 baseline Complete / frozen

28. Priorities and non-goals

Priorities for v1.0:

  1. Correctness and security over features.
  2. Post-quantum by default.
  3. Portability across platforms (Linux, Termux, macOS, Windows).
  4. Documentation that another person can follow.
  5. Honest measurement (benchmarks, audits).

Explicit non-goals for v1.0:

  • Distributed vault (v1.2+).
  • Multi-party computation (future).
  • Key escrow (never).
  • Blockchain integration.
  • GUI application (CLI + API only).
  • Mobile native apps (SDKs only).

29. References

  • docs/ARCHITECTURE.md
  • docs/THREAT_MODEL.md
  • docs/CRYPTOGRAPHY.md
  • docs/KEY_MANAGEMENT.md
  • docs/SECURITY_MODEL.md
  • docs/STORAGE.md
  • docs/API.md

End of document.