Voxfor Quantum TLS

Status: Internal Production Candidate – local release QA passed

A complete research post‑quantum TLS‑like protocol stack implementing:

• VLK‑1: Custom Module‑LWE-style research KEM with NTT optimization
• VOX‑SIG: Research hash‑based signatures (Lamport + Merkle) with atomic persistence
• QX509: VOX‑SIG-backed X.509‑style certificates
• VCPF‑2: ChaCha20‑Poly1305 AEAD record layer
• VQST: TLS 1.3‑like handshake with transcript hashing and key schedule
• CA Infrastructure: Full certificate authority with CRL support

This implementation now includes runnable production-style QA gates: strict Rust build/test/security checks, Redis-backed replay protection, Redis-backed VOX-SIG rollback protection, secret scanning, fuzzing, side-channel regression gates, an in-process VQST lab, and a real two-process bdikot.com localhost server/client lab.

Documentation

• README.md ← You are here (quick start, API examples)
• CRYPTOGRAPHIC_THEORY.md ← Deep dive: Lattice geometry, Quantum mechanics, DFP analysis
• ARCHITECTURE.md ← System design, protocol flows, implementation details
• SECURITY.md ← Threat model, known vulnerabilities, disclosure policy
• CONTRIBUTING.md ← Contribution guidelines, code standards
• docs/PRODUCTION_QA_GATES.md ← Release-blocking QA and deployment gates
• docs/CRYPTOGRAPHIC_AUDIT_SCALE.md ← Mandatory cryptographic review scale
• production-gates-remediation-20260704.md ← Latest remediation and QA evidence

What This Is

• A complete, functional research post‑quantum TLS-like stack
• Internally audited cryptographic implementations with production-style QA gates
• Extensively documented security properties and limitations
• Suitable for controlled internal deployments where the documented Redis and VOX-SIG state controls are used
• Exercised by a real Rust server process and real Rust client process over bdikot.com -> 127.0.0.1

What This Is NOT

• Not a drop‑in TLS replacement (requires careful integration)
• Not a browser/OpenSSL-compatible TLS implementation
• Not safe to run without the documented replay, rate-limit, certificate, and VOX-SIG state controls
• Not load‑balancer friendly unless replay protection and signing state are shared externally

---

Architecture & Components

Core Cryptographic Primitives

vlk1 – VLK‑1 Lattice KEM

• Module‑LWE-style key exchange with a post-quantum research security target
• NTT‑optimized polynomial multiplication (Cooley‑Tukey FFT)
• Side-channel-conscious arithmetic: branchless Barrett reduction and centered reduction
• IND‑CCA2-style construction: Fujisaki–Okamoto transform with implicit rejection
• Dual‑state keys with seed‑based secret key derivation
• Full test suite including NTT correctness vectors

voxsig – VOX‑SIG Hash‑Based Signatures

• Lamport one‑time signatures with 256‑bit hashes (SHA3‑256)
• Merkle tree authentication (2^16 signatures per key)
• SafeSigner wrapper providing:
  • Atomic on‑disk persistence (temp file + fsync + rename)
  • Thread‑safe signing with Mutex protection
  • Protection against local counter rollback
  • Optional RedisSigningStateGuard for VM snapshot/clone rollback detection
• Full preimage verification to prevent signature forgery
• Domain separation in Merkle tree (per‑level tags)
• Stateful – index reuse leaks private key (documented extensively)

qx509 – Quantum X.509 Certificates

• Custom certificate format with VOX‑SIG signatures
• Full X.509 extension support:
  • KeyUsage, BasicConstraints, SubjectAlternativeName
  • AuthorityKeyIdentifier, SubjectKeyIdentifier
  • ExtendedKeyUsage, CRLDistributionPoints
• Chain validator with:
  • Time‑based validity checking (with clock skew tolerance)
  • Key usage consistency validation
  • Recursive signature chain verification
  • Fail‑closed CRL checking (no bypass)
• DoS‑resistant PEM/DER parser:
  • Integer overflow protection
  • 10MB certificate size limit
  • Bounded length field parsing

Protocol & Infrastructure

vcpf2 – VCPF‑2 Record Layer

• ChaCha20‑Poly1305 AEAD encryption
• HKDF key derivation (RFC 5869 compliant)
• Explicit message limits (2³² records, rekey required)
• Directional key update support for read/write record keys
• Record framing with fragmentation/reassembly

vqst – VQST Handshake Protocol

• TLS 1.3‑like state machines for client/server
• Transcript hashing (SHA3‑256) for Finished MAC
• Key schedule with handshake/master/application secrets
• Security‑critical features:
  • Mandatory replay protection via NonceDatabase
  • Mandatory hostname verification (SAN/CN matching)
  • Mutual Finished message verification
  • Certificate chain validation with CRL checks
  • Protected encrypt_key_update / decrypt_key_update post-handshake control records
  • Fatal fail-closed state after Finished, AEAD record, or KeyUpdate authentication failure; derived secrets and record keys are cleared
• RateLimiter for DoS protection (IP‑based throttling)
• Optional RedisNonceStore for load-balanced replay protection
• Internal QA binaries for real localhost server/client validation:
  • vqst_internal_lab
  • vqst_bdikot_real_lab

ca – Certificate Authority

• RootCA and IntermediateCA with:
  • Atomic persistence of serial numbers and signing keys
  • Optional external SigningStateGuard for snapshot/clone rollback detection
  • Automatic key generation and self‑signed cert creation
  • JSON‑based key storage with temp file + fsync + rename
• CertificateIssuer for end‑entity certificates:
  • Server certificates (KeyUsage: DigitalSignature, KeyAgreement)
  • Client certificates (KeyUsage: DigitalSignature)
  • Automatic SAN, EKU, and CRL DP injection
• CRLManager with in‑memory revocation tracking

---

Security Properties & Limitations

What's Implemented Correctly

• Constant‑time-conscious cryptography:

  • Branchless Barrett reduction in NTT
  • Constant‑time centered reduction
  • CBD sampling for secret polynomials
  • Constant‑time MAC verification (subtle crate)

• Side‑channel hardening:

  • Implicit rejection in KEM (no decapsulation failure timing leak)
  • Zeroization of sensitive data (zeroize crate)
  • No known secret‑dependent branches in reviewed critical paths

• Robust validation:

  • Fail‑closed CRL checking (mandatory, no bypass)
  • Certificate chain validation with key usage checks
  • Integer overflow protection in DER parsing
  • DoS protection (10MB cert size limit)

• Cryptographic best practices:

  • HKDF for key derivation (RFC 5869)
  • Domain separation in hash functions, CertificateVerify, and Finished keys
  • Canonical handshake-envelope transcript hashing for Finished MAC
  • Explicit message limits (rekey after 2³² records)

Critical Limitations

1. Stateful Signatures (VOX‑SIG)

Problem: VOX‑SIG uses Lamport one‑time signatures. Reusing a signature index even once allows an attacker to recover the private key.

Mitigation in Code:

• SafeSigner provides atomic persistence (write → fsync → rename)
• RootCA and IntermediateCA use atomic counter persistence
• Extensive inline documentation warns about the issue

Deployment requirement:

• Single-node deployments may use SafeSigner plus NonceDatabase
• Restart-safe single-node replay protection may use persistent-nonce-db
• Load-balanced/internal-production deployments must use redis-production-guards
• VM/container snapshots that include signing keys are prohibited unless the Redis guard counter is audited before reuse

Production-style solution: use SafeSigner with an external monotonic guard such as RedisSigningStateGuard, and prohibit unmanaged VM/container snapshots of signing keys.

2. In‑Memory Replay Protection

Problem: NonceDatabase stores seen nonces in memory only. In multi‑server deployments, a replay attack can succeed by targeting a different server. The in-process store is bounded to avoid unbounded replay-cache growth under handshake storms, but that bound is a local DoS safety control, not distributed replay protection.

Why It Matters:

• Load balancing without sticky sessions → replay possible
• Server restart → all nonces forgotten
• HA/failover → replay across instances

Production Solution:

• Enable redis-production-guards and use RedisNonceStore for shared Redis-backed replay protection
• Or enable persistent-nonce-db and use NonceDatabase::with_persistence(...) for single-node restart safety only
• Use NonceDatabase::new_with_max_entries(...) when a single-node deployment needs an explicit local replay-cache capacity limit
• Use sticky sessions only as an additional operational control, not as the primary replay database

3. Network Layer Scope

What's Included:

• Cryptographic state machines and canonical handshake messages
• In-process localhost QA lab
• Two-process bdikot.com localhost QA lab

What's Still Application-Owned:

• Public TCP listener lifecycle
• Async I/O integration
• Connection pooling and service supervision
• No connection lifecycle manager; Server::with_rate_limiter is available but must be wired to peer IPs by the transport layer
• No session resumption or 0‑RTT support

What You Get:

• Handshake state machines (Client, Server)
• Message serialization/deserialization
• Cryptographic operations and validation
• Working server/client process examples in the internal lab binaries

Deployment Guidance

Safe for:

• Controlled internal deployments with the documented Redis/VOX-SIG guards
• Single‑instance servers with careful crash handling and no signer snapshots
• Development and testing environments
• Understanding PQ‑TLS protocol design

NOT safe for:

• Load-balanced production deployments without RedisNonceStore or an equivalent atomic shared NonceStore
• High‑availability setups with server failover unless the same external monotonic signing guard is shared by every signer process
• Multi‑region or distributed systems
• Any environment requiring FIPS or Common Criteria compliance

---

Usage Examples

Add to Cargo.toml

[dependencies]
voxfor-quantum-tls = { path = "." }

For Redis-backed replay and VOX-SIG rollback protection:

[dependencies]
voxfor-quantum-tls = { path = ".", features = ["redis-production-guards"] }

VLK‑1 KEM (Key Exchange)

use voxfor_quantum_tls::vlk1::{KeyPair, encapsulate, decapsulate};

// Generate quantum‑resistant keypair
let keypair = KeyPair::generate();

// Encapsulate (client side)
let (ciphertext, shared_secret_client) = encapsulate(keypair.public_key())?;

// Decapsulate (server side)
let shared_secret_server = decapsulate(&ciphertext, keypair.secret_key())?;

// Both sides now share the same secret
assert_eq!(shared_secret_client.as_bytes(), shared_secret_server.as_bytes());

VOX‑SIG Signatures (with SafeSigner)

use voxfor_quantum_tls::voxsig::safe_signer::SafeSigner;

// SAFE: Uses atomic persistence
let signer = SafeSigner::open_or_create("server.key")?;

let message = b"Hello, quantum world!";
let signature = signer.sign(message)?;

// Verify with public key
let verifying_key = signer.verifying_key()?;
voxfor_quantum_tls::voxsig::verify(&verifying_key, message, &signature)?;

QX509 Certificates & CA

use voxfor_quantum_tls::ca::{
    CertificateIssuer, IntermediateCA, IntermediateCAConfig, RootCA, RootCAConfig,
};
use voxfor_quantum_tls::voxsig::Keypair;

let root_dir = "./ca-root";
let intermediate_dir = "./ca-intermediate";

let mut root_ca = RootCA::initialize(root_dir, RootCAConfig::default())?;
let mut intermediate_ca = IntermediateCA::initialize(
    intermediate_dir,
    IntermediateCAConfig::default(),
    &mut root_ca,
)?;

let server_key = Keypair::generate();
let mut issuer = CertificateIssuer::new(&mut intermediate_ca);
let server_cert = issuer.issue_server_certificate(
    "server.example.com".to_string(),
    vec!["server.example.com".to_string()],
    server_key.verifying_key().to_bytes(),
    365,
)?;

VQST Handshake (Client)

use std::sync::Arc;
use std::time::Duration;
use voxfor_quantum_tls::vqst::{Client, NonceDatabase};
use voxfor_quantum_tls::ca::revocation::CRLManager;
use voxfor_quantum_tls::qx509::DistinguishedName;

// Setup security components
let nonce_db = Arc::new(NonceDatabase::new(Duration::from_secs(300)));
let crl_manager = Arc::new(CRLManager::new(DistinguishedName::new("Root CA")));

// Create client (enforces hostname verification)
let mut client = Client::new("server.example.com", nonce_db, crl_manager)?;

// Generate ClientHello
let client_hello = client.create_client_hello()?;

// Send to server, receive ServerHello, Certificate, CertificateVerify, Finished
// Then call client.process_server_hello(), process_certificate(), etc.

Important: This library provides cryptographic primitives and protocol state machines. You must:

• Wire state machines to actual network I/O (TCP/UDP)
• Implement connection management and timeouts
• Use SafeSigner for all VOX‑SIG signing operations
• Deploy with an external shared NonceStore for multi‑server setups

---

CLI Tool (voxctl)

A command‑line tool for certificate management is included:

# Show version and components
cargo run --bin voxctl version

# Generate Root CA
cargo run --bin voxctl gen-ca --dir ./ca --common-name "My Root CA"

Current Status:

• voxctl version Working
• voxctl gen-ca Working (creates ca.pem, ca.key, ca.pub, and serial state)

The CA functionality is fully implemented in the library (ca module) and can be used directly from Rust code (see examples above). The CLI wrapper is minimal but now performs real Root CA generation.

---

Development & Testing

Run Tests

# Full release gate
scripts/production_qa.sh

# Full release gate with Redis and real bdikot.com server/client process lab
export VQST_REDIS_URL=redis://127.0.0.1:6379/
scripts/production_qa.sh

# Before the bdikot.com lab, the local host must resolve to loopback:
getent hosts bdikot.com
# expected: 127.0.0.1 bdikot.com

# Full test suite only
cargo +nightly test --all-targets --all-features

# Run specific module tests
cargo +nightly test --lib vlk1::tests
cargo +nightly test --lib voxsig::tests

Benchmarks

# VLK‑1 KEM performance
cargo bench --bench vlk1_bench

# Results typically show:
# - KeyGen: ~1ms
# - Encapsulate: ~0.5ms
# - Decapsulate: ~0.7ms
# - NTT/INTT: ~10μs per polynomial

Code Quality

# Linting (strict mode)
cargo +nightly clippy --all-targets --all-features -- -D warnings

# Format check
cargo +nightly fmt --all -- --check

# Security audit
cargo audit

# Full local production gate: fmt/check/clippy/tests/audit/secret-scan/timing/leakage/fuzz
FUZZ_RUNS=256 TIMING_BATCHES=5 TIMING_ITERS=16 LEAKAGE_SAMPLES=256 bash scripts/production_qa.sh

Test Coverage

The project includes:

• Unit and integration tests in the current release gate
• NTT correctness test vectors (zero, constant, impulse, convolution, linearity)
• Compression idempotency tests (ensures no data loss)
• Signature forgery tests (tampered messages, wrong keys)
• Certificate chain validation (time, revocation, key usage)
• Replay attack tests (nonce reuse detection)
• Fatal record-authentication and KeyUpdate-authentication failure tests
• Constant‑time-conscious operation tests and review points
• Release-mode timing regression, Welch t-test leakage gates, real dudect-bencher benches, and Valgrind/Memcheck secret-taint gates for selected Finished, AEAD, and VLK1 decapsulation paths
• cargo-fuzz parser/codec/state targets for VQST handshakes and client state, VCPF2 records, QX509 certs/CRLs/PEM/DER, VOX-SIG signatures, and VLK1 wire formats
• Secret scanner that fingerprints suspected secrets without printing values
• Redis-backed distributed replay tests
• Redis-backed VOX-SIG rollback simulation
• Real Rust server process + real Rust client process over bdikot.com

Formal public claims of constant-time behavior require wider pinned-hardware dudect/ctgrind or equivalent secret-taint analysis plus external side-channel review; the in-repo gates are production regression and falsification controls.

---

Technical Details

Cryptographic Parameters

• VLK‑1 Security Target: post‑quantum research profile, not FIPS 203 ML-KEM

  • N = 256 (polynomial degree)
  • Q = 3329 (prime modulus, chosen so q ≡ 1 mod 512 for NTT)
  • K = 3 (module rank for the current research parameter set)
  • ζ = 17 (primitive 256th root of unity: 17^256 ≡ 1 mod 3329)
  • η = 2 (CBD noise parameter for constant‑time sampling)

• VOX‑SIG Security Target: post‑quantum research profile, not FIPS 204/205

  • Hash: SHA3‑256 (quantum preimage resistance: 2^128 ops via Grover)
  • Lamport key size: 256 bits × 2 × 256 = 16KB per OTS
  • Merkle height: 16 (2^16 = 65,536 signatures per tree)
  • Signature size: ~17KB (includes full public key for preimage verification)

• VCPF‑2 Parameters:

  • AEAD: ChaCha20‑Poly1305 (256‑bit keys)
  • Key derivation: HKDF‑SHA3‑256 (RFC 5869)
  • Message limit: 2³² records (prevents nonce reuse, enforced with rekey)

For mathematical foundations and security proofs, see CRYPTOGRAPHIC_THEORY.md

Feature Flags

[features]
default = []

# File-backed nonce storage for single-node restart-safe replay protection
persistent-nonce-db = []

# Redis-backed replay protection for load-balanced VQST deployments
redis-nonce-store = ["dep:redis"]

# Redis-backed monotonic VOX-SIG signing counter guard
redis-state-guard = ["dep:redis"]

# Enable both Redis production guards
redis-production-guards = ["redis-nonce-store", "redis-state-guard"]

# Local production-style QA labs (`vqst_internal_lab`, `vqst_bdikot_real_lab`)
internal-lab = ["redis-production-guards"]

# Async support (Tokio integration)
async = ["tokio", "async-trait"]

Performance Notes

• NTT optimization: Uses Cooley‑Tukey FFT with precomputed twiddle factors
• Memory usage: ~100KB per VLK‑1 keypair, ~50KB per VOX‑SIG keypair
• Signature size: VOX-SIG ~25KB with the default release Merkle height
• Handshake latency: ~3ms on modern hardware (single‑core)
• No heap allocation in hot paths: Most operations use stack or pre‑allocated buffers

Contributing

This is a ready-for-external-review cryptography project. Contributions welcome for:

• Additional distributed NonceStore backends (PostgreSQL/Memcached)
• Internal cryptanalysis artifacts, release-gate evidence, and formal protocol models
• Async/Tokio integration for vqst server
• Formal verification of NTT implementation
• Side‑channel attack testing and hardening
• NIST PQC standardization alignment

Please do NOT:

• Submit PRs that weaken security checks
• Remove safety documentation or warnings
• Introduce unsafe code without extensive justification

Author & Copyright

Designed and implemented from scratch by Netanel Siboni (@voxforlifetime). (@NetanelAI)

This library represents 3 months of intensive research and development to build a clean-slate, post-quantum secure communication stack without relying on legacy codebases (like OpenSSL).

Copyright © 2026 Netanel Siboni. All Rights Reserved.

Competitive Advantage

Why choose Voxfor Quantum TLS over OpenSSL, Rustls, or WolfSSL?

Feature	Voxfor Quantum TLS	OpenSSL (OQS)	Rustls	WolfSSL
Language	Pure Rust (Memory Safe)	C (Unsafe)	Rust + C Wrappers	C (Unsafe)
Post-Quantum	Native (Built-in)	Plugin Required	External C Libs	Plugin Required
TCB Size	< 5,000 LOC (Auditable)	> 500,000 LOC	Medium (dep. heavy)	> 100,000 LOC
Signatures	Atomic Persistence (Safe)	Unsafe (Assumes HSM)	Stateless Only	Unsafe
Integration	Rust-first crate API	DLL/SO Hell	C Compiler Needed	Complex Build
Architecture	Clean-Slate Design	Legacy Debt (1998)	Modern	Embedded Focus

Key Differentiators

1. Supply Chain Security: Most "Rust" TLS libraries wrap legacy C code (aws-lc, ring, liboqs). Voxfor keeps its protocol and math layers in Rust, avoiding C build chains in the core implementation.

2. Safety by Design: We solve the "Stateful Signature" problem with Atomic Persistence. Competitors simply warn you "don't reuse keys" and let you fail. We enforce safety at the filesystem level.

3. True Agility: While others wait for OpenSSL to merge patches, Voxfor implements a fully integrated stack. We own the math, the primitives, and the protocol.

License & Support

License: MIT License

This project is proudly open-source. You are free to use, modify, and distribute it under the permissive MIT terms.

Commercial Support

While the code is free, integrating post-quantum cryptography correctly is complex. For enterprise support, custom integration, or architectural consulting, please contact:

📧 netanel@voxfor.com

Disclaimer: This software is provided "as is". It has extensive internal QA, unit tests, Redis-backed guards, fuzzing, dudect/ctgrind-style falsification gates, and real Rust server/client process testing over bdikot.com. That is not independent cryptanalysis or production-grade cryptographic approval. Use only in environments where the documented deployment controls are followed and the operator accepts responsibility for running a custom cryptographic protocol.

---

Built with care for the post‑quantum era