Hybrid by default
Every key exchange and signature can run classical and post-quantum algorithms together, combined through standard key derivation, so protection holds if either fails.
Platform & Architecture
One platform.
Every layer quantum-safe.
The ElvasAI platform applies post-quantum cryptography at each layer of the operating system and network stack. It forms a single chain of trust, from the silicon that boots a device to the APIs it serves.
Design Principles
How the platform is engineered
Constant-time implementations
Cryptographic code is engineered to avoid secret-dependent timing and memory access, and hardened against power and fault-injection analysis.
Policy-driven agility
Algorithms and parameter sets are selected by central policy, so organisations can respond to new attacks or standards without redeploying.
Hardware-anchored trust
Keys and measurements are anchored in TPM 2.0 and HSMs, and integrity is proven remotely through attestation.
Observable security
Handshake, attestation, policy and drift events are exported for SIEM and SOAR, so cryptography becomes part of security operations.
Standards only
NIST FIPS 203, 204 and 205 and SP 800-208 algorithms, with IETF hybrid protocol constructions. No proprietary cryptography.
Reference Architecture
Defence in depth, layer by layer.
Every ElvasAI product covers a specific layer of the operating system and network stack. QScan audits all of them, so you can see where quantum-vulnerable cryptography remains and what replaces it.
- Key encapsulation
- ML-KEM (FIPS 203), hybrid with X25519
- Signatures
- ML-DSA (FIPS 204), SLH-DSA (FIPS 205)
- Firmware signing
- LMS / XMSS (NIST SP 800-208)
- Implementation
- Constant-time, side-channel hardened
QSCAN continuous cryptographic inventory across L1–L5
Cryptographic Foundations
Built on NIST-standardised post-quantum algorithms
ElvasAI products use the algorithms NIST finalised in August 2024, chosen for each layer by security level, key and signature size, and performance.
| Algorithm | Standard | Function | NIST level | Public key | Ciphertext / Signature | Used in |
|---|---|---|---|---|---|---|
| ML-KEM-768 | FIPS 203 | Key encapsulation | 3 | 1,184 B | 1,088 B | QVPN QGATE |
| ML-KEM-1024 | FIPS 203 | Key encapsulation | 5 | 1,568 B | 1,568 B | QVPN |
| ML-DSA-65 | FIPS 204 | Digital signature | 3 | 1,952 B | 3,309 B | QVPN QGATE |
| ML-DSA-87 | FIPS 204 | Digital signature | 5 | 2,592 B | 4,627 B | QBOOT |
| SLH-DSA-SHA2-128s | FIPS 205 | Hash-based signature | 1 | 32 B | 7,856 B | QBOOT |
| LMS / XMSS | SP 800-208 | Stateful hash-based signature | — | Depends on parameter set | QBOOT | |
| RSA-2048 · ECDH · ECDSA | Classical | Broken by Shor's algorithm | 0 | 32–256 B | 32–256 B | QSCAN detects |
- NIST FIPS 203
- NIST FIPS 204
- NIST FIPS 205
- NIST SP 800-208
- NIST IR 8547
- NSA CNSA 2.0
- IETF RFC 9370
- CycloneDX CBOM
Supports your security & compliance programme
NIST CSF 2.0Identify, Protect and Detect functions
NIST SP 800-207Zero Trust Architecture
ISO/IEC 27001:2022Annex A 8.24 · Use of cryptography
PCI DSS v4.0Req. 12.3.3 · Cryptographic inventory
EU DORAICT risk & cryptographic controls
MITRE ATT&CK®Technique-mapped threat coverage
Ready to make your organisation quantum-safe?
Book a technical briefing or a QScan readiness assessment with our engineers.