Repository Review

PQC Implementation Audit

A code-level review of QBITEL's current custom and domain-specific PQC implementations, separating strong foundations from guarded wrappers and prototype domain modules.

Production-grade signals

Rust Falcon engine and LMS/XMSS state handling

Guarded core wrappers

ML-KEM and ML-DSA are viable only with strict provider enforcement

Domain modules needing redesign

Automotive, industrial, and healthcare examples still rely on placeholders

Review frame

This assessment focuses on what the code currently enforces: key generation, signing, verification, state handling, trust anchors, and whether the advertised security property is actually delivered by the implementation.

PQC Implementation Review

Filter the current maturity of each custom and domain-specific module.

This view reflects the code as reviewed in the repository: which parts are strong, which are guarded by strict configuration, and which still rely on simplified or placeholder cryptography.

Production-grade signals

Rust Falcon engine and LMS/XMSS state handling

Guarded core wrappers

ML-KEM and ML-DSA are viable only with strict provider enforcement

Domain modules needing redesign

Automotive, industrial, and healthcare examples still rely on placeholders

Platform core

ML-KEM core wrapper

The ML-KEM engine fails closed in strict mode, but it still exposes explicit insecure random fallbacks when strict mode is disabled.

Guarded core

Code reference

ai_engine/crypto/mlkem.py:192-193, 255-266, 311-315, 359-363

What the code currently shows

Strict mode blocks fallback initialization when no provider is available.
Fallback key generation and shared-secret generation are intentionally insecure.
Safe enough as a wrapper only if production always enforces strict mode.

Recommended next step

Keep strict mode on for every production path.
Make fallback unavailable outside tests and developer fixtures.

Platform core

ML-DSA core wrapper

The signature wrapper has the right fail-closed default, but its non-strict fallback signs with random bytes and verify returns true.

Guarded core

Code reference

ai_engine/crypto/dilithium.py:178-179, 242-253, 297-301, 342-346

What the code currently shows

Strict mode blocks insecure fallback at initialization.
Fallback signing creates random signatures with no authenticity guarantee.
Fallback verification returns true, which is unacceptable in production.

Recommended next step

Treat the fallback path as test-only code.
Add startup assertions so domain modules cannot silently run without a real provider.

State management

LMS and XMSS state handling

The stateful signature implementation is comparatively mature, with atomic persistence, exclusive locking, and state advancement before signing.

Strong foundation

Code reference

ai_engine/crypto/lms_xmss.py:252-260, 264-274, 701-782, 1181-1254

What the code currently shows

State is written with an atomic replace pattern.
Signing takes an exclusive lock before reading or advancing state.
Leaf indices advance before signature generation to avoid reuse after crashes.

Recommended next step

Keep this implementation as a reference for safety-critical PQC state management.
Add recovery and stress tests around concurrent access and crash scenarios.

Rust dataplane

Rust Falcon dataplane engine

The Rust Falcon engine uses real pqcrypto operations for key generation, signing, and verification, with reasonable domain-level configuration hooks.

Strong foundation

Code reference

rust/dataplane/crates/pqc_tls/src/falcon.rs:277-307, 385-403, 455-473, 511-530

What the code currently shows

Key generation uses pqcrypto_falcon directly.
Detached signing and verification use concrete Falcon primitives.
Domain configs exist for automotive, aviation, and healthcare.

Recommended next step

Turn advisory config flags into enforced behavior where needed.
Implement actual compression and compliance controls instead of metadata-only toggles.

Automotive

Automotive V2X group signatures

This module presents itself as group signatures with identity escrow and revocation, but critical pieces are still hash-based placeholders and the verifier uses the group manager key incorrectly.

Unsafe as implemented

Code reference

ai_engine/domains/automotive/v2x_group_signatures.py:404-411, 486-510, 800-817, 1021-1036, 1041-1050, 1083-1087

What the code currently shows

Identity escrow is a SHAKE256 hash, not actual encryption under the manager key.
Per-signature escrow is also a simplified hash-based construction.
Verification checks signatures against the group manager verification key, which is not a real group-signature verification flow.
Revocation update tokens do not line up with the verifier-side matching logic.

Recommended next step

Do not market this as production-ready anonymity or traceability.
Replace the placeholder scheme with a real group-signature construction or re-scope it as pseudonymous signatures.

Industrial

Industrial TESLA++ broadcast authentication

The sender signs commitments with ML-DSA, but receiver-side verification accepts any non-empty signature because trusted public-key validation is missing.

Unsafe as implemented

Code reference

ai_engine/domains/industrial/tesla_broadcast_auth.py:533-545, 748-781

What the code currently shows

Commitment signing uses a real ML-DSA path.
Commitment verification explicitly avoids cryptographic verification and only checks that the signature is present.
This breaks the trust anchor for the whole TESLA commitment chain.

Recommended next step

Add PKI-backed public-key lookup and real signature verification before using this in any deployment.
Fail closed when trusted sender identity or key material is unavailable.

Healthcare

Healthcare verifiable credentials

Selective disclosure and predicate proofs are placeholder constructions, and verifier logic only checks proof shape rather than issuer trust, inclusion, and proof correctness.

Prototype

Code reference

ai_engine/domains/healthcare/verifiable_credentials.py:395-405, 407-426, 469-497

What the code currently shows

Merkle proofs are reduced to a single hash over sibling values.
Predicate proofs are hashes of booleans with random salt, not zero-knowledge proofs.
Presentation verification checks length and presence rather than actual cryptographic validity.

Recommended next step

Treat this as a design prototype rather than a deployable credential system.
Integrate real issuer verification, Merkle inclusion proofs, and mature ZK primitives before productizing it.

Use the audit to guide positioning and hardening work

The core message should emphasize governed PQC migration and strong foundational primitives, while the prototype domain modules are hardened or re-scoped.

Quick Start Guide Star on GitHub Enterprise Support