This post is in continuation of previous post on Sept-2,2025 related to Pre-quantum ciphers used for data in motion and rest. Post Quantum cryptography is taking shape in modern AI servers though it is still in early stages. There are two specific areas used for encryption and decryption like TLS (SSL) Protocols which use RSA, Diffie-Hellman (DH), and Elliptic Curve Cryptography (ECC) or combination like ECDHE (elliptic curve Diffie Hellman) for key exchange and digital signatures whereas AES (Advanced Encryption Standard) ciphers are used for encrypting the actual communication channel once keys are established and note all these ciphers fall in pre-quantum cryptography. Then there are very specific use cases for AI models to use encryption and decryption like:
- In order to prevent attacker to steal the model or making it unusable Model encryption is used where AI model’s weights and parameters can be encrypted and stored, with the decryption keys secured in a Trusted Execution Environment (TEE).
- Another use case of these ciphers is in Confidential computing of running AI workloads inside a hardware-based TEE to protect AI model even when it is in active memory. TEEs ensure that the decryption and computation occur in a secure, isolated environment.
- Finally, Application-layer encryption uses data represented as “embeddings” (numerical representations of data) protected before it is stored in a database. This ensures that even a compromised server cannot access the plaintext data.
Even though algorithms like AES and SHA-2/3 still remain quantum resistant with key sizes doubled from 128b to counteract Grover’s algorithm (e.g., AES-256). Post-Quantum Key Encapsulation Mechanisms (KEMs) ML-KEM (module lattice key encapsulation mechanism), HQC (hamming quasi cycle error correcting code), NTRU (also lattice cryptography using Nth order truncated polynomial ring units), integrated into TLS 1.3, SSH, and VPN protocols. These post-quantum KEMs replace or augment classical key exchange algorithms in hybrid deployments (where classical and PQ algorithms are combined) to maintain real-time secure communication. It is time to summarize above observations for ciphers in a tabular form:
| Type of Cipher | Algorithm Example | Use Case |
| Pre-Quantum | ECDH (Elliptic curve Diffie Hellman), AES-256, SHA-256 | key exchange and encryption for TLS |
| Post-Quantum | FIPS-203: ML-KEM, HQC and NTRU (not FIPS 203 as of now) | Quantum resistant key exchange in TLS |
| Still Viable | AES-256, SHA-3 | Quantum resistant for bulk encryption and message integrity |
ML-KEM can be implemented in hardware although ML-KEM being available in crypto libraries like OpenSSL, GnuTLS, and NSS. This allows for post-quantum key exchange in TLS connections. It is also used in quantum-safe VPNs by allowing users to add ML-KEM to key exchange. Cloud providers are also integrating ML-KEM into their core services to secure data and communications that support AI workflows. Note for practical use cases Hybrid approach is sometimes more useful that combines pre and post quantum ciphers. Open Quantum Safe (OQS) library integrates PQC algorithms into standard protocols like TLS.
Key question need to be asked before using PQC (post quantum crypto) is the performance since some of it is highly compute intensive thus expensive, few metrics to evaluate it are summarized in the table below:
| Metric | Relevance | Description |
| TLS Handshake overhead | For establishing secure communication for AI applications | TLS handshakes using ECDHE (elliptical curve Diffie Hellman) vs. hybrid post-quantum key exchanges (ECDHE+BIKE, ECDHE+SIKE) show the overall latency impact to blockchain RPC nodes and API endpoints. This might be a factor if model or data is sharded across various servers. Peer authentication, channel setup in blockchain servers might be a good use case here. |
| Time/latency to generate Public/Private Key Pairs and also to Encrypt/Decrypt data using KEM (key encapsulation mechanisms) | Key Generation and Usage Efficiency and overhead | ECDHE SECP256R1 key agreement(millisec) per key exchange in hybrid setting or Kyber512 (ML-KEM 512) key exchange(millisecs) might be metric here used in wolfSSL benchmark |
| Time/Latency to generate and verification of Digital signatures | Only for Digital Signature Authenticated applications | |
| CPU and memory Usage both in User and kernel modes | Important for resource constraint devices and also power indicator. Note PQC compute is matrix centric thus optimizations there would be useful for PQC. | This impacts the real AI application which is making use of this mechanism. |
| PQC material sizes | Key and Signature sizes are relevant to performance | Impacts network packet sizes and bandwidth besides storage and memory requirements |
| AI Inference Impact | Real Time inference metrics (ops/sec) at higher level need to be evaluated. | |
| AI Training impact | Many Model specific parameters like tokens/sec ingested or resource contentions on memory , IO and network need to be measured. Training time is overall metric that might be effected. | Network conditions are not same all the time during training thus needs to be accounted like packet loss, bandwidth usage modulation |
| Tools and Benchmarks | OpenSSL or OQS are prime candidates as they exercise TLS protocols. | |
| Network Usage and System Energy | On/Off PQC or other cryptography methods to determine the overhead in case feasible. |
ISA extensions must be used for the processor supported in case these are not implemented using hardware primitives for PQC needs like:
ARM: Neon SIMD for parallel Data ops needed in lattice math for PQC
X86: AVX-512 for polynomial and symmetric crypto ops
RISC V: SHA 3 and Modular arithmetic’s extensions exist besides SIMD/Vector extensions.
Please note this writeup is not exhaustive but a consideration for roadmaps as qubits processors and its scaling catchup happens in time that could put the tradition pre-quantum cryptographic ciphers useless or not very secure for servers like blockchain and the ones used for confidential computing.