| Document Classification | Public Technical Specification |
| Scope | Transport Layer Cryptographic Architecture |
| Revision Policy | Updated upon cryptographic standard evolution |
Architecture Overview
Below is the system model of ZenthraCore's Post-Quantum Transport Enclave (v1.1). Incoming traffic from the public edge uses classical compatibility, while all traffic past the cryptographic boundary enforces post-quantum standards.
- Terminology and Normative Language
- Architectural Classification
- Normative Requirements
- Threat Model (Formalized)
- Informative Section — Design Rationale
- Performance Metrics (Observed)
- Cryptographic Configuration Appendix
- Migration Strategy (Formalized)
- Security Governance Principles
- Architectural Positioning Statement
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.
Binding architectural requirements and rules.
Design rationale, benchmark analysis, and operational commentary.
Architectural Classification
| Architecture Type | Segmented Post-Quantum Transport Enclave |
| Deployment Model | Hybrid Compatibility Edge + Strict PQ Core |
| Operational Status | Production |
Normative Requirements
3.1 Transport Protocol
3.1.1 Public 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.
Current browser ecosystem limitations preclude PQ-only external endpoints.
3.1.2 Internal 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.
Hybrid fallback inside the PQ enclave is explicitly forbidden.
3.2 Downgrade 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.3 Cryptographic 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.
Threat Model (Formalized)
Formalized threat vectors and corresponding mitigation objectives inside the enclave:
- Passive interception
- Traffic archival
- Future quantum decryption
Protect with ML-KEM to ensure forward secrecy.
- Negotiation interference
- Cipher manipulation
- Group substitution
Downgrade attempts must terminate handshakes.
- Passive sniffing
- Partial network access
All boundary traffic remains under strict PQ.
Informative Section — Design Rationale
5.1 Why 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 transition
Performance Metrics (Observed)
Values represent measured behavior in current deployment; updated periodically.
6.1 Handshake Overhead
~8–15%
vs classical X25519
2–4×
ML-DSA vs classical ECDSA
None
No system degradation observed
6.2 Throughput 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.3 Failure Characteristics
- Explicit handshake rejection on classical group attempt.
- Explicit failure when signature algorithm mismatch occurs.
- No silent fallback observed.
Cryptographic Configuration Appendix
7.1 Internal PQ Segment Configuration
| Protocol | TLS 1.3 |
| KEM Group | mlkem768 |
| Signature | mldsa44 |
| Cipher Suite | TLS_AES_256_GCM_SHA384 |
- X25519 / secp256r1
- secp384r1
- TLS 1.2 or earlier
- All legacy ciphers
7.2 Edge Configuration Summary
- TLS 1.3
- Strong classical KEMs
- Modern AEAD cipher suites
- TLS 1.2 or earlier
- Weak cipher suites
- RSA key exchange
Migration Strategy (Formalized)
Security Governance Principles
- No exaggerated quantum immunity claims.
- No silent fallback mechanisms inside the enclave.
- No undocumented hybrid exceptions inside the boundary.
- Explicit downgrade policy with alerts.
- Explicit trust boundary definition.
- Measurable cryptographic enforcement.
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
| Version | Status | Description |
|---|---|---|
| 1.1 | Current | Normative formalization and downgrade policy clarification. |
| 1.0 | Archived | Initial release. |
