Document Classification: Public Technical Specification
Scope: Transport Layer Cryptographic Architecture
Revision Policy: Updated upon cryptographic standard evolution
Formal Security Whitepaper
Post-Quantum Segmented
Transport Architecture
Architecture Overview
Fig. 1 — Segmented post-quantum transport enclave. Classical compatibility at the edge; strict PQ-only enforcement inside the boundary.
1.Terminology and Normative Language
The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, and MAY in this document are to be interpreted as described in RFC 2119.
Normative Sections
Binding architectural requirements
Informative Sections
Design rationale and operational commentary
2.Architectural Classification
3.Normative Requirements
3.1Transport Protocol
3.1.1Public Edge
- ▸MUST support TLS 1.3 only
- ▸MUST NOT support TLS 1.2 or earlier
- ▸MUST NOT enable legacy cipher suites
- ▸MAY support classical key exchange mechanisms for compatibility
Rationale: Current browser ecosystem limitations preclude PQ-only external endpoints.
3.1.2Internal Post-Quantum Segment
- ▸MUST operate exclusively on TLS 1.3
- ▸MUST enforce ML-KEM (mlkem768) as the only allowed key exchange group
- ▸MUST NOT allow X25519, P-256, or any classical group
- ▸MUST require ML-DSA-based signature verification
- ▸MUST terminate the handshake on group mismatch
- ▸MUST terminate the handshake on signature mismatch
- ▸MUST terminate the handshake on protocol downgrade attempt
3.2Downgrade Resistance
Inside the PQ enclave:
- ▸Classical key exchange fallback MUST NOT exist
- ▸Cipher suite negotiation MUST NOT include classical alternatives
- ▸Protocol version negotiation MUST reject any version other than TLS 1.3
- ▸Handshake failure MUST be logged and treated as a security event
3.3Cryptographic Boundary
The cryptographic boundary SHALL be defined between Edge (nginx) and PQ Gate. All transport across this boundary MUST comply with the PQ-only enforcement policy.
4.Threat Model (Formalized)
Capabilities
- •Passive interception
- •Traffic archival
- •Future quantum decryption attempt
Mitigation Objective
Internal transport MUST be protected with ML-KEM to ensure quantum-resistant forward secrecy.
Capabilities
- •TLS negotiation interference
- •Cipher manipulation
- •Group substitution
Mitigation Objective
Downgrade attempts MUST result in handshake termination.
Capabilities
- •Passive sniffing
- •Partial network access
Mitigation Objective
All inter-component traffic across the boundary MUST remain encrypted under PQ-only transport.
5.Informative Section — Design Rationale
5.1Why Segmentation Instead of Full PQ
As of 2026, mainstream browsers do not support ML-KEM, and ecosystem components (databases, caches, service mesh layers) lack PQ-native TLS. A fully PQ external endpoint would result in total loss of compatibility.
Operational PQ enforcement
Backward compatibility
Real performance evaluation
Controlled cryptographic transition
6.Performance Metrics (Observed)
Values represent measured behavior in current deployment; updated periodically.
6.1Handshake Overhead
~8–15%
Latency increase vs X25519
~2–4×
Certificate size increase (ML-DSA vs ECDSA)
None observed
Service degradation under load
6.2Throughput Impact
- ▸Bulk data transfer performance unaffected (symmetric AES-GCM is unchanged)
- ▸Overhead isolated to handshake phase
- ▸PQ transport overhead is front-loaded and amortized over persistent connections
6.3Failure Characteristics
- ▸Explicit handshake rejection on classical group attempt
- ▸Explicit failure when signature algorithm mismatch occurs
- ▸No silent fallback observed
7.Cryptographic Configuration Appendix
7.1Internal PQ Segment Configuration
Enabled
Disabled
7.2Edge Configuration Summary
Enabled
Disabled
8.Migration Strategy (Formalized)
Phase 1CURRENT
Hybrid public edge + strict internal PQ enclave
Current operational state.
Phase 2
Hybrid External Support
When browsers implement hybrid KEM:
External edge SHOULD enable hybrid KEM.
Internal PQ enforcement SHALL remain strict.
Phase 3
PQ-Only Optional Endpoint
When browser ecosystem stabilizes:
PQ-only external endpoint MAY be introduced.
Compatibility endpoint MAY remain temporarily.
Phase 4
Extended PQ Adoption
When supported by ecosystem:
Service-to-service PQ transport.
PQ-capable database connections.
PQ-aware service mesh.
9.Security Governance Principles
No exaggerated quantum immunity claims
No silent fallback mechanisms
No undocumented hybrid exceptions
Explicit downgrade policy
Explicit trust boundary definition
Measurable cryptographic enforcement
10.Architectural Positioning Statement
This system does not claim complete post-quantum internet exposure.
It operates a production-enforced, downgrade-resistant post-quantum transport enclave within a compatibility-constrained external ecosystem.
The architecture reflects deliberate cryptographic transition strategy rather than marketing alignment.
Version History
Download
Same content as this page, in PDF format.